boost :: shared_mutex выдает в 1.50

Привет Fellow Boost энтузиастов

Мы столкнулись с проблемой с shared_mutex и копались в источнике буста.
Мы не можем сказать, является ли это тупиковым случаем, или мы просто не понимаем общее
реализация мьютекса для блокировки чтения / записи.

Заявка :

У нас есть карта map< Ptr*, data> это должно быть создано и опрошено несколькими потоками.
Тем не мение, самый из Ptr* значения являются общими, поэтому после быстрого прогрева
То, что мы считаем, это шаблон практически без вставок в карту. Поэтому мы думали использовать
шаблон чтения / записи для управления доступом к карте, например

boost::mutex& lock_;
bool found = false;
{
shared_lock<boost::shared_mutex> slock(lock_);
(search the map to see if you have key)
if (keyFound) {
found = true;
}
}
if (!found) {
upgrade_lock<boost::shared_mutex> ulock(lock_);
(search the map again to see if the key has been inserted)
if (key still found) {
upgrade_to_unique_lock<boost::shared_mutex> wlock(ulock);
insert into the map & do whatever
}
}

Исходный shared_lock должен быть уничтожен, когда блок выходит из области видимости,
сделать upgrade_lock единственной блокировкой, если исходная shared_lock не удалась.

Замечания:

Все наши темы застряли на несколько дней

_lll_lock_wait or pthread_mutex_lock

Покопавшись в реализации boost :: shared_mutex, мы обнаружим, что
одна общая блокировка «state_changed» внутри мьютекса и для того, чтобы
shared_lock или unique_lock для успешного выполнения, он должен получить общую блокировку state_changed
как для строительства замка, так и для разрушения. Кажется, что unique_lock войдет в
состояние, в котором это может освободить scoped_lock для state_changed, но мы не можем сказать.
В любом случае, мы не можем сказать, почему потоки в основном блокируются на длительные периоды времени.
со спорадическим прогрессом — это не совсем тупик, а что-то близкое.

Любая помощь приветствуется.

Сэм Эпплтон