2011-11-28 9 views
8

He estado buscando en C++ 0x hilos y tienen este código:función de rosca con pasado por el vector de referencia es lento para iniciar

#include <vector> 
#include <iostream> 
#include <thread> 
void TestFunc(const vector<int>& vVec) 
{ 
    cout << "in"<<endl; 
} 

int main() 
{ 

    int sizer = 400000000; 

    vector<int> vTest(sizer); 
    for(int f=0; f<sizer; f++) 
     vTest[f] = f; 


    cout << "V created." << endl; 

    thread one(TestFunc, vTest); 

    one.join();  

} 

Como se puede ver que sólo pasa un vector de un hilo. Lo que no entiendo es que hay una pausa después de que aparece el mensaje "V created". Originalmente esto (supuse) era el vector que se estaba copiando para usar en la función. Para detener esto pasé por referencia, pero esto no hizo diferencia.

La demora parece ser proporcional al tamaño del vector que indica que todavía está copiando (o haciendo algo con la matriz). Si pruebo el mismo experimento sin hilos y llamo directamente a la función, la demora está allí cuando paso por valor pero no cuando paso por referencia como esperaba.

Intenté lo mismo utilizando hilos Boost en lugar de C++ 0x (aunque he leído que son muy parecidos) y obtuve el mismo resultado.

¿Hay alguna razón para este comportamiento o me he perdido algo cegadoramente obvio? Gracias.

Lo siento, publicado el código de prueba equivocado. Corregido Editar: Agregado incluye según lo solicitado.

compilado con: g ++ 44 -std = C++ 0x -lpthread tester.cpp prueba ... como tengo GNU 4.4 instalado al lado del compilador GNU estándar que viene con mi Linux (CentOS -o) que no es compatible con C++ 11.

+0

la parte más cara de TestFunc es la traza, no los parámetros que pasan. parece que C++ 0x no admite la creación de hilos – BruceAdi

+0

@Mahesh: ¿En qué sistema? Esto es solo 400 millones y se ajustará cómodamente en un int de 32 bits. –

+0

@BruceAdi: En C++ 11 hilos son obligatorios según el estándar, y al menos gcc-4.6 los admite, y funcionan, los uso todos los días. – hirschhornsalz

Respuesta

17

Solo estoy especulando, ya que no ha publicado la versión del código que usa hilos, pero sospecho que su problema es que, de forma predeterminada , std::bind (o boost::bind) haga copias de todos los argumentos que vincula. Para evitar esto, puede usar std::ref o std::cref.

Para hacer este concreto, es probable que estés usando bind así:

std::bind(TestFunc, vTest) 

su lugar, debe utilizar de esta manera:

std::bind(TestFunc, std::cref(vTest)); 
+0

Esto me parece un poco torpe. ¿No hay forma de que 'bind' adivine que la función quiere una referencia y que debe almacenar una referencia? – Omnifarious

+0

+1 Acabo de probarlo con su código, y tiene razón. Al usar _std :: cref_, la demora desaparece. Bien visto. – hirschhornsalz

+7

@Omnifarious: no estoy seguro de que sea deseable. El comportamiento esperado de un cierre (que, esencialmente, es lo que 'bind 'es) es que los objetos pasados ​​como argumentos" sobreviven "mientras exista el cierre. Este no sería el caso si 'bind' solo almacenara referencias para todos los parámetros de un tipo de referencia. O, para verlo de otra manera: copiar todos los argumentos es un comportamiento predeterminado seguro. Pasar referencias conlleva cierto peligro y, por lo tanto, debe solicitarse explícitamente; Además, el explícito 'ref' o' cref' es una bandera clara para cualquiera que haga mantenimiento más adelante. –

-1

¿Dónde están los hilos aquí? Parece que el bucle for está causando el retraso al que te refieres. Nada inusual aquí, ya que está asignando un vector de tamaño 200000000.

+3

-1: Esta sería una gran respuesta si la demora no fuera entre ver 'V creado'. y en'. – Omnifarious

Cuestiones relacionadas