Вскоре я начну работу над параллельной версией алгоритма уточнения сетки с использованием общей памяти.
Профессор университета отметил, что мы должны быть очень осторожны в отношении безопасности потоков, поскольку ни компилятор, ни stl не знают о потоке.
Я искал этот вопрос, и ответ зависел от компилятора (некоторые пытались быть в некоторой степени осведомленными о потоках) и plattform (если системные вызовы, используемые компилятором, являются потокобезопасными или нет).
Итак, в linux компилятор gcc 4 создает поточный код для нового оператора?
Если нет, то какой способ преодолеть эту проблему? Может быть, заблокировать каждый вызов новому оператору?
Вам будет очень сложно найти платформу, которая поддерживает потоки, но не имеет потокобезопасности new. На самом деле безопасность потока new (и malloc) является одной из причин, по которой она настолько медленная.
С другой стороны, если вы хотите безопасный поток STL, вы можете рассмотреть Intel TBB, в котором есть контейнеры с поддержкой потоков (хотя не все операции с они являются потокобезопасными).
Как правило, оператор new является потокобезопасным - однако гарантии безопасности потоков для вызовов в STL и стандартная библиотека регулируются стандартом - это не означает, что они не знают нити - они, как правило, имеют очень четко определенные гарантии безопасности потоков для определенных операций. Например, итерация через список в режиме "только для чтения" является потокобезопасной для нескольких читателей, в то время как повторение списка и создание обновлений - нет. Вы должны прочитать документацию и посмотреть, каковы различные гарантии, хотя они не являются обременительными, и они имеют смысл иметь смысл.
Пока я говорю о концепциях, которые я не использовал, я считаю, что если вы используете разделяемую память, вы, вероятно, захотите убедиться, что используете только типы POD и используете новое размещение.
Во-вторых, если вы используете разделяемую память, как это обычно понимается в Linux-системах, то вы можете использовать несколько процессов - не потоки, выделять память и "делать что-то" - использовать разделяемую память в качестве уровня связи, Если это так, то безопасность потоков вашего приложения и библиотек не важна - важно, однако, безопасность потоков для чего-либо, использующего выделение разделяемой памяти! Это другая ситуация, чем запуск одного процесса со многими потоками, и в этом случае вопрос о безопасности потока нового оператора является актуальной проблемой и может быть устранен путем размещения нового, если это не так, или путем определения ваших собственных распределителей.
Ну, это не окончательный ответ на мой вопрос, просто я узнал, что Google внедрил высокопроизводительный многопоточный malloc.
Итак, если вы сомневаетесь в том, что ваша реализация является потокобезопасной, возможно, вам следует использовать Инструменты Google Performance.