Всем привет,

Кто-нибуть знает где взять реализацию сабжа?
Сейчас у меня RWlock + stl map.
В качестве RWlockа использую найденый где то лет 10 назад CRWMonitor. У него нет апгрейда read в write.
Из-за этого если работа может потребовать модификацию, то я вынужден лочить единолично write. Хотя часто в ходе разбора мапа модификация и не требуется. А я заранее этого не знаю.
Софт весь из себя асинхронный по самое небалуйся. И тут я влезаю с мапами своими...

Здравствуйте, Kubyshev Andrey, Вы писали:

KA>Всем привет,

KA>Кто-нибуть знает где взять реализацию сабжа?
KA>Сейчас у меня RWlock + stl map.
KA>В качестве RWlockа использую найденый где то лет 10 назад CRWMonitor. У него нет апгрейда read в write.
KA>Из-за этого если работа может потребовать модификацию, то я вынужден лочить единолично write. Хотя часто в ходе разбора мапа модификация и не требуется. А я заранее этого не знаю.
KA>Софт весь из себя асинхронный по самое небалуйся. И тут я влезаю с мапами своими...

Советую почитать Anthony Williams — C++ Concurrency in Action.

Суть в следующем — если возможно, используйте мапы, основанные на хешах. За счёт этого вы получите бакеты значений, с которыми можно работать асболютно независимо.

Не понимаю, зачем нужен апргейд read во write. Что это за метод мапа, которому такое потребуется?

KA>Кто-нибуть знает где взять реализацию сабжа?

1) http://threadingbuildingblocks.org/files/documentation/a00130.html
2) Если не хочется тащить что-то внешнее, то можно использовать мютексы и локи из boost и вместо одного мапа завести N мапов и N мютексов, выбирая мап как hash(key) % N.

KA>В качестве RWlockа использую найденый где то лет 10 назад CRWMonitor. У него нет апгрейда read в write.
Как вы себе представляете "апдейт из read в write"?
Представьте себе два потока которые одновременно пытаются перейти из read в write. То есть они оба уже захватили объект на read и при переходе во write будут ждать пока объект будет свободен от всех остальных read и write юзеров. То есть — зависнут. Концептуальный дедлок. Из read во write мона переходить тока "отпуская" лок вообще, с соответствующими допущения о том что защищаемый объект во время этого перехода мог быть изменен.

Здравствуйте, ononim, Вы писали:

KA>>В качестве RWlockа использую найденый где то лет 10 назад CRWMonitor. У него нет апгрейда read в write.
O>Как вы себе представляете "апдейт из read в write"?
O>Представьте себе два потока которые одновременно пытаются перейти из read в write. То есть они оба уже захватили объект на read и при переходе во write будут ждать пока объект будет свободен от всех остальных read и write юзеров. То есть — зависнут. Концептуальный дедлок. Из read во write мона переходить тока "отпуская" лок вообще, с соответствующими допущения о том что защищаемый объект во время этого перехода мог быть изменен.

просто дополнительный мьютекс на апгрейд нужен.
http://www.boost.org/doc/libs/1_47_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts.upgrade_lockable

You will always get what you always got
  If you always do  what you always did

PD>Советую почитать Anthony Williams — C++ Concurrency in Action.
PD>Суть в следующем — если возможно, используйте мапы, основанные на хешах. За счёт этого вы получите бакеты значений, с которыми можно работать асболютно независимо.
PD>Не понимаю, зачем нужен апргейд read во write. Что это за метод мапа, которому такое потребуется?

Это нужно для того что во время энумерации или какого то поиска в мапе я захотел удалить один из элементов.
Ты имеешь в виду что если я буду использовать какой то другой мар нежели чем std::map то при таком удалении ничего не поломается у ридеров?

A>>>В качестве RWlockа использую найденый где то лет 10 назад CRWMonitor. У него нет апгрейда read в write.
O>>Как вы себе представляете "апдейт из read в write"?
O>>Представьте себе два потока которые одновременно пытаются перейти из read в write. То есть они оба уже захватили объект на read и при переходе во write будут ждать пока объект будет свободен от всех остальных read и write юзеров. То есть — зависнут. Концептуальный дедлок. Из read во write мона переходить тока "отпуская" лок вообще, с соответствующими допущения о том что защищаемый объект во время этого перехода мог быть изменен.
J>просто дополнительный мьютекс на апгрейд нужен.
J>http://www.boost.org/doc/libs/1_47_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts.upgrade_lockable

This is an extension to the multiple-reader / single-write model provided by the SharedLockable concept: a single thread may have upgradable ownership at the same time as others have shared ownership.

То есть если ты планируешь в будущем делать потенциальный shared->exclusive апгрейд та сразу захватывешь read access таким upgradable lock'ом. И пока ты держишь upgradable lock — никто другой не может захватить ugradable lock. Полезно лишь в ситуации когда ты заранее знаешь (или догадываешься) что в будущем тебе понадобится write lock, и эта ситуация происходит достаточно редко по сравнению когда он тебе не понадобится, ибо ugradable lock эксклюзивен сам по себе.

Здравствуйте, Kubyshev Andrey, Вы писали:

PD>>Советую почитать Anthony Williams — C++ Concurrency in Action.
PD>>Суть в следующем — если возможно, используйте мапы, основанные на хешах. За счёт этого вы получите бакеты значений, с которыми можно работать асболютно независимо.
PD>>Не понимаю, зачем нужен апргейд read во write. Что это за метод мапа, которому такое потребуется?

KA>Это нужно для того что во время энумерации или какого то поиска в мапе я захотел удалить один из элементов.
KA>Ты имеешь в виду что если я буду использовать какой то другой мар нежели чем std::map то при таком удалении ничего не поломается у ридеров?

Я вспоминал интерфейс стандартного мапа и не вспомнил методов, которые бы требовали read-only доступ, но потом, возможно, требовали бы и write доступ. Предлагаю тебе набросать тут интерфейс твоего мапа. Может люди чего дельного подскажут.
Пока не ясно, зачем нужно объединять чтение и запись в одну операцию.