C ++ Thread Safety Сводка

Question

Я хотел бы получить краткую информацию о том, что именно потокобезопасно в C ++, как в соответствии с текущим стандартом и C ++ 0x, так и на практике (вообще говоря, но также и в моем случае с gcc 4.5.1).

Для контейнеров STL, насколько я понимаю, безопасность потоков не гарантируется в соответствии с действующим стандартом.Правда ли, что на практике они являются потокобезопасными для одного писателя, для нескольких читателей (на gcc и, возможно, на большинстве современных компиляторов)?Это гарантировано C ++ 11?

А как насчет типов POD?Я знаю, что стандарт ничего не гарантирует, но мне сказали, что на практике все они безопасны для чтения и записи.Конечно, даже что-то простое, например, оператор приращения, может все еще нуждаться в синхронизации, поскольку может быть несколько операций чтения и записи.

Меня в первую очередь интересуют ответы, но за ответы за ответы будет принята благодарность.

Answer 1

Ничто из того, что вы упомянули, не является потокобезопасным, ни по стандарту, ни на практике.

Причина, по которой стандарты не предписывают безопасность нитей, заключается в том, что безопасность нитей сопряжена с определенными затратами. В общем, C ++ старается не давать вам того, о чем вы не просите. Если вам нужна безопасность нитей, вы должны создать ее самостоятельно. Это верно даже в C ++ 0x, который включает в себя различные примитивы синхронизации.

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

В случае типов POD операции чтения и записи также могут выполняться в несколько этапов. Этот самый простой пример - 64-разрядное целое число на 32-разрядной машине. Чтобы прочитать или установить значение, нужно как минимум две инструкции. Еще раз, это означает, что если поток пытается прочитать или обновить значение, пока другой поток находится в процессе его обновления, результаты будут непредсказуемыми.

Answer 2

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

C ++ 0x не говорит много (вообще?) Конкретно о контейнерах в отношении безопасности / совместного использования потоков, но говорит о назначениях и тому подобном. В конце концов, все получается примерно так же - даже если объект находится в контейнере, вы читаете / записываете данные, и вам нужно синхронизировать, когда / если хотя бы один поток может изменить данные.

Данные POD на самом деле не сильно меняются: модификации, как правило, требуют синхронизации. Обычно существует некоторое подмножество типов данных, для которых операции обычно являются атомарными, но члены этого подмножества зависят от платформы. Как правило, он включает типы вплоть до собственного размера слова аппаратного обеспечения, выделенного с «естественным» выравниванием; все остальное открыто для гораздо большего вопроса.

Answer 3

Ни в C, ни в C ++ не встроены примитивы параллелизма, как, скажем, в java с synchronised.Это (я считаю) преднамеренное - даже в современных версиях - чтобы избежать накладных расходов, когда они не нужны.Unix не поддерживал легковесные процессы в первые дни, поэтому многопоточность была в основном проблемой ядра.

Различные проприетарные библиотеки потоков (например, потоки Solaris) были произведены поставщиками, и отрасль в конечном итоге стандартизировала библиотеку pthread, первоначально с чисто потоковой моделью в пользовательском пространстве (блокировка вызовов, таких как ввод-вывод, блокировала бы все потоки) и позже с поддержкой потоков ядра.Windows, OS / 2 и различные другие операционные системы предлагают проприетарные средства потоков.

C / C ++ предназначены для работы в системах, которые могут иметь или не иметь поддержку потоков, и для эффективной работы - поэтому поддержка потоков является необязательной.дополнительно.Одна из философий дизайна C ++ заключается в том, что программисту не нужно платить за функции, которые они не используют.Можно было бы возразить о достоинствах этого подхода в эпоху многоядерных машин, но если предположить, что «весь мир - это ПК», то уже несколько десятилетий считается основной ловушкой при написании переносимого кода на Си.

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

Answer 4

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

В C ++ 0x у меня мало идей;на самом деле не проверяет эту область Стандарта.