C ++ новый оператор безопасности потоков в Linux и GCC 4

Question

Скоро я начну работать над параллельной версией алгоритма уточнения сетки с использованием разделяемой памяти.

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

Я искал этот вопрос, и ответ зависел от компилятора (некоторые пытаются быть немного ориентированным на потоки) и платформы (если системные вызовы, используемые компилятором, поточно-ориентированы или нет) .

Итак, в linux компилятор gcc 4 создает потокобезопасный код для нового оператора?

Если нет, то как лучше всего решить эту проблему ? Может, заблокировать каждый звонок новому оператору?

Answer 1

Вам будет очень трудно найти платформу, которая поддерживает потоки, но не имеет потоковой безопасности new. На самом деле, безопасность потоков new (и malloc) является одной из причин, по которой он так медленен.

С другой стороны, если вам нужен потокобезопасный STL, вы можете рассмотреть Intel TBB , который имеет контейнеры с поддержкой потоков (хотя не все операции над ними являются потокобезопасными).

Answer 2

Обычно оператор new является потокобезопасным, однако гарантии безопасности потоков для вызовов в STL и стандартную библиотеку регулируются стандартом - это не означает, что они не знают потоков - они, как правило, имеют очень четкие определения. гарантии безопасности резьбы для определенных операций. Например, перебор списка в режиме «только для чтения» является потокобезопасным для нескольких читателей, а перебор списка и внесение обновлений - нет. Вы должны прочитать документацию и посмотреть, каковы различные гарантии, хотя они не такие обременительные и имеют смысл.

Answer 3

Ну, это не окончательный ответ на мой вопрос, просто я узнал, что Google реализовал высокопроизводительный многопоточный malloc .

Итак, если вы сомневаетесь, является ли ваша реализация поточно-ориентированной, возможно, вам следует использовать Google Performance Tools .

Answer 4

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

Во-вторых, если вы используете разделяемую память, как это обычно понимается в системах Linux, то вы можете использовать несколько процессов - не потоков, чтобы выделить память и «делать вещи» - используя разделяемую память в качестве уровня связи , Если это так, тогда безопасность потоков вашего приложения и библиотек не важна, однако, важно то, что безопасность потоков для всего, что использует распределение общей памяти! Это другая ситуация, чем запуск одного процесса со многими потоками, и в этом случае вопрос о безопасности потоков нового оператора является действительной проблемой и может быть решен путем размещения нового, если это не так, или путем определения ваших собственных распределителей.