Vector STL y seguridad de hilo

Digamos que tengo un vector de N elementos, pero hasta n elementos de este vector tienen datos significativos. Un subproceso actualizador actualiza el elemento nth o n + 1st (luego establece n = n + 1), también comprueba si n está demasiado cerca de N y llama a vector :: resize (N + M) si es necesario. Después de la actualización, el hilo llama a varios hilos secundarios para leer hasta la enésima información y hacer algunos cálculos.

Se garantiza que los hilos secundarios nunca cambien o eliminen datos (de hecho, no se borran datos) y Updater llama a los niños justo después de que finaliza la actualización.

Hasta ahora no ha ocurrido ningún problema, pero quiero preguntar si puede ocurrir un problema durante la reasignación del vector a un bloque de memoria más grande, si hay algunos subprocesos de trabajo secundarios que quedan de la actualización anterior.
¿O es seguro usar vectores, ya que no es seguro para subprocesos, en un caso de multiproceso?

EDITAR: dado que solo se realiza la inserción cuando el actualizador llama a vector :: resize (N + M, 0), ¿hay alguna solución posible a mi problema? Debido al gran rendimiento del vector STL, no estoy dispuesto a reemplazarlo por un vector bloqueable o, en este caso, ¿hay algún vector performant, conocido y sin lockings?

Quiero preguntar si puede ocurrir un problema durante la reasignación de vector a un bloque de memoria más grande, si hay algunos subprocesos secundarios de trabajo de la actualización anterior.

Sí, esto sería muy malo.

Si está utilizando un contenedor de varios subprocesos y al menos un subproceso puede realizar alguna acción que pueda modificar el estado del contenedor, el acceso al contenedor debe estar sincronizado.

En el caso de std::vector , cualquier cosa que cambie su tamaño (notablemente, inserciones y borrados) cambia su estado, incluso si no se requiere una reasignación (cualquier inserción o borrado requiere que los datos de contabilidad de tamaño interno de std::vector sean actualizado).


Una solución a su problema sería hacer que el productor asigne dinámicamente el std::vector y use un std::shared_ptr > para poseerlo y darle este std::shared_ptr a cada uno de los consumidores.

Cuando el productor necesita agregar más datos, puede asignar dinámicamente un nuevo std::vector con un nuevo tamaño más grande y copias de los elementos del antiguo std::vector . Luego, cuando separas nuevos consumidores o actualizas a los consumidores con los nuevos datos, simplemente necesitas darles std::shared_ptr al nuevo std::vector .

¿De qué manera sus trabajadores deciden trabajar en el hilo de datos seguro? ¿Hay alguna señal entre los trabajadores y el productor? Si no, definitivamente hay un problema por el cual el productor podría hacer que el vector se mueva mientras todavía se está trabajando. Aunque esto podría resolverse trivialmente moviéndose a std::deque lugar (tenga en cuenta que std::deque invalida los iteradores en push_back pero las referencias a los elementos no se ven afectadas).

He hecho mi propio GrowVector. Funciona para mí y es realmente rápido.

Enlace: QList, QVector o std :: vector multi-threaded use