C ++ параллельные ассоциативные контейнеры? - PullRequest
2 голосов
/ 01 марта 2010

Я ищу ассоциативный контейнер некоторого вида, который обеспечивает безопасный одновременный доступ для чтения и записи, при условии, что вы никогда не читаете и не пишете одновременно элемент .

В основном у меня есть эта настройка:

Тема 1: Создание A, Запись A в контейнер, Отправка A по сети.

Поток 2: Получить ответ на A, прочитать A из контейнера, выполнить некоторую обработку.

Я могу гарантировать, что мы когда-либо будем писать только один раз, хотя мы можем получить несколько ответов для A, которые будут обрабатываться последовательно. Это также гарантирует, что мы никогда не читаем и не пишем A одновременно, поскольку мы можем получить ответ на A только после его отправки.

Так что в основном я ищу контейнер, в котором запись в элемент не мешает другим элементам. Например, std::map (или любая другая реализация на основе дерева) не удовлетворяет этому условию, поскольку его базовая реализация представляет собой красно-черное дерево, поэтому любая заданная запись может перебалансировать дерево и взорвать любые параллельные операции чтения.

Я думаю, что std::hash_map или boost::unordered_set могут работать для этого, просто исходя из моего предположения, что нормальная реализация хеш-таблицы будет соответствовать моим критериям, но я не уверен, и не могу найти какую-либо документацию, которая бы скажи мне. Кто-нибудь еще пытался использовать их аналогично?

Ответы [ 2 ]

1 голос
/ 01 марта 2010

STL не дает каких-либо твердых гарантий относительно потоков, поскольку стандарт C ++ вообще не упоминает потоки. Я не знаю о бусте, но я был бы удивлен, если бы его контейнеры давали гарантии параллелизма.

А как насчет concurrent_hash_map из TBB ? Я нашел это в связанном с этим вопросе .

0 голосов
/ 01 марта 2010

Реализация обычной хеш-таблицы имеет перефразировку при увеличении количества хранимых элементов, так что это, вероятно, не исключение, если вы знаете, что этого не происходит.

Я бы посмотрел на структуры, используемые для функциональных языков (например, посмотрите на http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf), но учтите, что те, о которых я сейчас думаю, зависят от сборки мусора.

...