multithreading: cómo los datos de proceso en un vector, mientras que el vector se está poblada?

Question

I tiene una sola-roscado Linux aplicación que me gustaría hacer paralelo. Se lee un archivo de datos, crea objetos, y los coloca en un vector. Entonces se llama a un método de cómputo intensivo (0,5 segundos +) en cada objeto. Quiero llamar al método en paralelo con la creación de objetos. Mientras que he mirado QT y TBB, estoy abierto a otras opciones.

tenía planeado comenzar el hilo (s) mientras que el vector estaba vacío. Cada uno llamaría makeSolids (abajo), que tiene un bucle while que funcionaría hasta interpDone == true y todos los objetos del vector han sido procesados. Sin embargo, soy un n00b cuando se trata de rosca, y he estado buscando una solución lista para usar.

QtConcurrent::map(Iter begin,Iter end,function()) se ve muy fácil, pero no puedo usarlo en un vector que está cambiando de tamaño, puede hacerlo? Y cómo le diría que esperar para más datos?

También miré tbb de Intel, pero se veía como mi hilo principal detendría si utilicé parallel_for o parallel_while. Que apesta, desde que se recomienda su administrador de memoria (mmgt de cascada abierto tiene un rendimiento pobre cuando multiproceso).

/**intended to be called by a thread
\param start the first item to get from the vector
\param skip how many to skip over (4 for 4 threads)
*/
void g2m::makeSolids(uint start, uint incr) {
  uint curr = start;
  while ((!interpDone) || (lineVector.size() > curr)) {
    if (lineVector.size() > curr) {
      if (lineVector[curr]->isMotion()) {
        ((canonMotion*)lineVector[curr])->setSolidMode(SWEPT);
        ((canonMotion*)lineVector[curr])->computeSolid();
      }
      lineVector[curr]->setDispMode(BEST);
      lineVector[curr]->display();

      curr += incr;
    } else {
      uio::sleep(); //wait a little bit for interp
    }
  }
}

EDIT:? En resumen, ¿cuál es la forma más sencilla de procesar un vector, al mismo tiempo que el hilo principal está poblando el vector

Answer 1

Es difícil saber si ha estado pensando en este problema profundamente y hay más de lo que está dejando en, o si está pensando en algo más de él, o si son sólo desconfiar de rosca.

La lectura del archivo y la creación de los objetos es rápido; el método es lento. La dependencia es cada ctor consecutiva depende del resultado de la ctor anterior - un poco extraño - pero por lo demás no hay problemas de integridad de datos, de modo que no parece ser otra cosa que necesita ser protegido por el mutex y tal

.

¿Por qué es esto más complicado que algo como esto (en crudo pseudo-código):

while (! eof)
{
    readfile;
    object O(data);
    push_back(O);
    pthread_create(...., O, makeSolid);
}


while(x < vector.size())
{
    pthread_join();
    x++;
}

Si no desea bucle en el combinaciones en su principal y luego desovar cerca de un hilo que esperar en ellos haciendo pasar un vector de TID.

Si el número de creado objetos / hilos es loco, utilizar un grupo de subprocesos. O poner un contador de bucle es la creación de limitar el número de hilos que se pueden crear antes de ejecutar se unen queridos.

Answer 2

En primer lugar, se beneficie de enhebrar es necesario encontrar tareas igualmente lenta para cada hilo a hacer. Usted dijo que su procesamiento por objeto toma .5s +, ¿cuánto tiempo de leer su archivo / objeto la creación de opinión? Fácilmente podría ser una décima o una milésima parte de ese tiempo, en cuyo caso su enfoque multi-hilo se va a producir un beneficio neglegible. Si ese es el caso, (sí, voy a responder a su pregunta original pronto en caso no lo es) y luego pensar en forma simultánea el procesamiento de varios objetos. Dada su procesamiento lleva bastante tiempo, la creación del hilo superior no es terriblemente importante, por lo que podría tener simplemente la lectura de archivos / objeto hilo principal de la creación de generar un nuevo subproceso y dirigirla hacia el objeto recién creado. El hilo principal, entonces continúa la lectura / creación de objetos posteriores. Una vez que se leen todos los objetos / creado, y todos los hilos de procesamiento puso en marcha, el hilo principal "une" (espera a) los subprocesos de trabajo. Si esto va a crear demasiadas hebras (miles), a continuación, poner un límite a lo lejos por delante se permite que el hilo principal de conseguir: puede leer / crear 10 objetos y luego unirse a 5, a continuación, leer / crear 10, unirse a 10, de lectura / crear 10, 10, etc. unirse hasta que termine.

Ahora, si realmente desea que la lectura / crear para estar en paralelo con el procesamiento, pero el procesamiento se va a serializar, a continuación, puede seguir utilizando el enfoque anterior, pero después de unirse a cada objeto. Eso es un poco raro si usted está diseñando esta sólo con este enfoque en mente, pero bueno, ya que puede experimentar fácilmente con el paralelismo de procesamiento de objetos por arriba.

Como alternativa, puede utilizar un enfoque más complejo que simplemente consiste en el hilo principal (que el sistema operativo crea cuando se inicia el programa), y un solo subproceso de trabajo que el hilo principal debe comenzar. Ellos deben ser coordinadas utilizando un mutex (una variable garantizar mutuamente exclusiva, lo que significa no-concurrente, acceso a los datos), y una variable de condición que permite que el subproceso de trabajo para bloquear de manera eficiente hasta que el hilo principal ha proporcionado más trabajo. El términos - variable de exclusión mutua y el estado -. Son los términos estándar en la rosca de POSIX que los usos de Linux, por lo que deben ser utilizados en la explicación de las bibliotecas particulares que le interesa Resumiendo, las esperas subproceso de trabajo hasta que la lectura principal / crean hilo lo transmite una señal de alerta que indica otro objeto está listo para su procesamiento. Es posible que desee tener un mostrador con índice del último totalmente creado, listo para el procesamiento de objetos, por lo que el subproceso de trabajo puede funcionar de forma recuento de objetos procesados ??y moverse a lo largo de las listas de comprobación antes de volver a la variable de estado.

Answer 3

@Caleb: bastante - Tal vez debería haber hecho hincapié en Activo hilos. El hilo de interfaz gráfica de usuario siempre debe ser considerado como uno.