Станд. C++:: ориентированный на многопотоковое исполнение набор?

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

Например, посмотрите здесь: текст ссылки

Поскольку set - это контейнерный класс, MSDN должен сказать следующее о поточной безопасности контейнеров.

Отдельный объект поточно-безопасен для чтения из нескольких потоков. Например, для объекта A безопасно читать A из потока 1 и из потока 2 одновременно.

Если один объект записывается одним потоком, то все считывают и записывают в этот объект в том же или другие потоки должны быть защищены. Например, для объекта A, если поток 1 записывает в A, то потоку 2 необходимо запретить чтение или запись в A.

Безопасно читать и записывать в один экземпляр типа, даже если другой поток читает или пишет в другой экземпляр того же типа. Например, для объектов A и B одного типа,

Ни один из контейнеров STL не является потокобезопасным, поэтому std :: set , в частности, нет.

В вашем случае проблема даже не в безопасности потоков, хотя: Вы просто делитесь объектом в нескольких потоках (хорошо) и изменяете его в одном потоке (тоже хорошо). Но, как вы уже сказали, изменение контейнера делает недействительными его итераторы. Произойдет ли это в том же потоке или в другом потоке, не имеет значения, поскольку это все еще тот же контейнер .

Ой! В §23.1.2.8 указано, что вставка не отменяет итераторы.

STL-документация Dinkumware содержит следующий абзац по этой теме. Вероятно (как указано в тексте) справедливо для большинства реализаций.

Для объектов-контейнеров, определенных в стандартная библиотека C ++, например STL Контейнеры и объекты шаблона класс basic_string, это реализация широко следует принятые практики, изложенные для SGI STL:

Несколько потоков могут безопасно читать один и тот же объект-контейнер. (Есть незащищенные изменяемые подобъекты внутри объект контейнера.)

Два потока могут безопасно манипулировать разными объектами контейнера. того же типа. (Нет незащищенные общие статические объекты внутри типа контейнера.)

Вы должны защитить от одновременного доступа к контейнеру объект, если хотя бы один поток изменение объекта. (Очевидное примитивы синхронизации, такие как те, что находятся в библиотеке потоков Dinkum, не будет разрушен контейнером объект.)

Таким образом, не предпринимается никаких попыток обеспечить что атомарные операции над контейнером объекты потокобезопасны; но это достаточно легко сделать общий контейнер объекты, которые являются потокобезопасными в соответствующий уровень детализации.

Простое объяснение: если поток A перемещает итераторы через контейнер, он смотрит на внутренние компоненты контейнера. Если поток B изменяет контейнер (даже операцию, которая не делает недействительным итератор, имеющийся у A), поток A может столкнуться с проблемами, потому что B обманывает внутренние компоненты контейнера, возможно, находясь в (временно) недопустимом состоянии. Это вызывает сбой в потоке A.

Проблема НЕ в самих итераторах. Это когда им нужны структуры данных контейнера, чтобы найти позицию, в которой у вас возникнут проблемы.

Все просто.

Да. Один из способов справиться с этой ситуацией - заставить каждый поток блокировать общий мьютекс перед доступом к одному и тому же заданному объекту. Убедитесь, что вы используете методы RAII для блокировки и разблокировки мьютекса.