c++ - Seguridad de subprocesos de std:: map para operaciones de solo lectura

multithreading stl

Question

Tengo un std :: map que uso para asignar valores (ID de campo) a una cadena legible. Este mapa se inicializa una vez cuando mi programa se inicia antes de que se inicie cualquier otro subproceso, y después de eso nunca más se modifica. En este momento, le doy a cada subproceso su propia copia de este mapa (bastante grande) pero obviamente es un uso ineficiente de la memoria y retrasa el inicio del programa. Así que estaba pensando en darle a cada hilo un puntero al mapa, pero eso plantea un problema de seguridad del hilo.

Si todo lo que estoy haciendo es leer el mapa usando el siguiente código:

std::string name;
//here N is the field id for which I want the human readable name
unsigned field_id = N; 
std::map<unsigned,std::string>::const_iterator map_it;

// fields_p is a const std::map<unsigned, std::string>* to the map concerned.
// multiple threads will share this.
map_it = fields_p->find(field_id);
if (map_it != fields_p->end())
{
    name = map_it->second;
}
else
{
    name = "";
}

¿Funcionará o hay problemas con la lectura de un std :: map desde múltiples hilos?

Nota: Actualmente estoy trabajando con Visual Studio 2008, pero me gustaría que esto funcione en la mayoría de las implementaciones principales de STL.

Actualización: Ejemplo de código editado para corrección de const.

Answer 1

Debería estar bien. Puede usar const referencias a él si desea documentar / imponer el comportamiento de solo lectura.

Tenga en cuenta que la corrección no está garantizada (en principio, el mapa podría elegir rebalancearse en una llamada para find ), incluso si utiliza solo métodos const (una implementación realmente perversa podría declarar el árbol como mutable). Sin embargo, esto parece bastante improbable en la práctica.

Answer 2

Esto funcionará desde varios subprocesos siempre que su mapa siga siendo el mismo. El mapa que utiliza es inmutable de facto, por lo que cualquier búsqueda hará una búsqueda en un mapa que no cambie.

Aquí hay un enlace relevante: http://www.sgi.com/tech/stl/thread_safety.html

La implementación SGI de STL es segura para subprocesos solo en el sentido de que los accesos simultáneos a distintos contenedores son seguros, y los accesos de lectura simultáneos a contenedores compartidos son seguros. Si varios subprocesos acceden a un solo contenedor, y al menos un subproceso puede escribir, entonces el usuario es responsable de garantizar la exclusión mutua entre los subprocesos durante los accesos del contenedor.

Usted cae en la categoría de "accesos de lectura simultáneos a contenedores compartidos".

Nota: esto es cierto para la implementación de SGI. Necesitas verificar si usas otra implementación. De las dos implementaciones que parecen ser ampliamente utilizadas como alternativa, STLPort ha incorporado la seguridad de subprocesos como sé. Aunque no sé sobre la implementación de Apache.

Answer 3

Sí lo es.

Ver publicación relacionada con la misma pregunta sobre std :: set:

¿Es seguro el subproceso C ++ std :: set?