El estándar C++ ofrece ciertas garantías de enhebrado para todas las clases en la biblioteca estándar de C++. Estas garantías pueden no ser lo que esperaría que fueran, pero para todas las clases de bibliotecas C++ estándar se hacen ciertas garantías de seguridad de subprocesos. Sin embargo, asegúrese de leer las garantías, ya que las garantías de subprocesamiento de los contenedores estándar de C++ generalmente no se alinean con lo que usted desearía. Para algunas clases se hacen garantías diferentes, generalmente más fuertes, y la respuesta a continuación se aplica específicamente a los contenedores. Los contenedores tienen esencialmente las siguientes garantías de hilo de seguridad:
- puede haber múltiples lectores concurrentes del mismo contenedor
- si hay un escritor, no habrá más escritores y no hay lectores
Normalmente no son lo que las personas querrían como garantías de seguridad de subprocesos, pero son muy razonables dada la interfaz de los contenedores estándar: están destinados a ser utilizados de manera eficiente en ausencia de múltiples hilos de acceso. Agregar cualquier tipo de bloqueo para sus métodos interferiría con esto. Más allá de esto, la interfaz de los contenedores no es realmente útil para ninguna forma de bloqueo interno: generalmente se usan múltiples métodos y los accesos dependen del resultado de accesos previos. Por ejemplo, después de haber comprobado que un contenedor no es empty(), se puede acceder a un elemento. Sin embargo, con el bloqueo interno no hay garantía de que el objeto aún esté en el contenedor cuando realmente se acceda a él.
Para cumplir con los requisitos que brindan las garantías anteriores, probablemente deba utilizar alguna forma de bloqueo externo para los contenedores accedidos simultáneamente. No sé sobre los contenedores de impulso, pero si tienen una interfaz similar a la de los contenedores estándar, sospecho que tienen exactamente las mismas garantías.
Las garantías y requisitos se dan en 17.6.4.10 [res.on.objects] párrafo 1:
El comportamiento de un programa es indefinido si las llamadas a funciones de biblioteca estándar a partir de diferentes hilos pueden introducir un datos carrera. Las condiciones bajo las cuales esto puede ocurrir se especifican en 17.6.5.9. [Nota: la modificación de un objeto de un tipo de biblioteca estándar que se comparte entre hilos corre el riesgo de un comportamiento indefinido a menos que los objetos de ese tipo se especifiquen explícitamente como compartibles sin razas de datos o el usuario proporcione un mecanismo de bloqueo. -endnote]
... y 17.6.5.9 [res.on.data.races]. Esta sección esencialmente detalla la descripción más informal en el no.
Esto tiene que ser un dup. Pero, no, ninguno de los contenedores estándar es seguro para subprocesos. – smparkes
Vea también: http://stackoverflow.com/questions/1999122/how-to-define-threadsafe – ergosys
No es un engaño, pero está relacionado: http://stackoverflow.com/questions/1099513/threadsafe-vector-class- for-c – ergosys