C++ seguridad de hilo de operador nuevo en linux y gcc 4

Question

Pronto comenzaré a trabajar en una versión paralela de un algoritmo de refinamiento de malla utilizando memoria compartida.

Un profesor de la universidad señaló que debemos ser muy cuidadosos con la seguridad de los hilos porque ni el compilador ni el stl son conscientes de los hilos.

Busqué esta pregunta y la respuesta dependía el compilador (algunos tratan de ser algo hilo-consciente) y la Plataforma (si las llamadas del sistema utilizados por el compilador son hilos de proceso seguro o no).

Entonces, en Linux, el compilador gcc 4 produce un código seguro para subprocesos para el nuevo operador?

Si no, ¿cuál es la mejor manera de solucionar este problema ? ¿Tal vez bloquear cada llamada al nuevo operador?

Answer 1

Tendrá que buscar muy duro para encontrar una plataforma que admita hilos pero que no tenga un hilo seguro new. De hecho, la seguridad de subprocesos de new (y malloc) es una de las razones por las que es tan lento.

Si desea un subproceso seguro STL, por otro lado, puede considerar Intel TBB que tiene contenedores de detección de subprocesos (aunque no todas las operaciones en ellos son seguras para subprocesos).

Answer 2

Generalmente, el operador new es seguro para hilos, sin embargo, las garantías de seguridad de subprocesos para las llamadas al STL y la biblioteca estándar se rigen por el estándar; esto no significa que no estén al hilo. Suelen tener garantías muy definidas de seguridad de hilo para ciertas operaciones. Por ejemplo, iterar a través de una lista en modo de solo lectura es seguro para múltiples lectores, mientras que iterar a través de una lista y hacer actualizaciones no lo es. Tienes que leer la documentación y ver cuáles son las diversas garantías, aunque no son tan onerosas y tienden a tener sentido.

Answer 3

Si bien hablo de conceptos que no he utilizado, creo que debería mencionar que si está usando memoria compartida, entonces probablemente quiera asegurarse de usar solo tipos de POD y utilizar la ubicación nueva.

En segundo lugar, si está utilizando memoria compartida como se entiende comúnmente en sistemas Linux, entonces puede estar utilizando múltiples procesos, no hilos, para asignar memoria y "hacer cosas", utilizando la memoria compartida como comunicación capa. Si este es el caso, entonces la seguridad de subprocesos de su aplicación y las bibliotecas no son importantes. Sin embargo, lo importante es la seguridad de subprocesos de cualquier cosa que use la asignación de memoria compartida. Esta es una situación diferente a ejecutar un proceso con muchos subprocesos, en cuyo caso preguntar por la seguridad de subprocesos del nuevo operador ES una preocupación válida, y podría resolverse colocando nuevos si no es así, o definiendo sus propios asignadores.

Answer 4

Bueno, esta no es una respuesta definitiva a mi pregunta, solo que descubrí que Google implementó un alto rendimiento de múltiples subprocesos malloc.

Por lo tanto, si tiene dudas acerca de si su implementación es segura para subprocesos, quizás deba usar Google Performance Tools.