Foro de elhacker.net

Hola, antes de meterme en Mutex etc, quería saber si se puede detener de esta manera un thread en C++, o apartir de una funcion externa que busque un valor la devuelva, y apartir de ese nuevo valor, haga false la condicion de bucle del thread y salga de este.

Probé con un volatile bool y con una variable global pasandola como argumento a la funcion del thread, pero creo que una vez pasada como argumento la funcion la trata como variable estática, luego si la cambio en otra parte del código no influye en el valor de la función del thread.

bool on = true;
	thread ok(trabaja, on, a);//hay que pasarle el bool a través de una funcion
system("pause");
on=false;
ok.get();
cout << "yano hay thread!!";

trabaja (bool on, string a)
{
while(on){
/...
}
}

Visto que eso no funciona, pensé en crear una función que busque el valor externo y lo devuelva, pero a primeras no se me ocurre nada, seguiré pensando en ello.

Y sino con mutex como se podría hacer?

Saludos.

El código es incorrecto. Le tienes que pasar el bool como referencia, sinó tendrá un valor inmutable.

thread ok(trabaja, &on, a);
 
trabaja(bool *on, string a)

o

thread ok(trabaja, ref(on), a);
 
trabaja(bool &on, string a)

"ok.get()"? "ok.join()"

Gracias socio, problema resuelto.

Luego para salir del bucle sería con el asterisco:

while(*on){..}

Saludos y gracias.  :) ;)

A todo esto, e pregunto ahora, ¿porque usar mutex si con esto podríamos hacer lo mismo y de manera más sencilla sin producir tantos errores?

Ya que para controlar la entrada a la ejecucion de un code con mutex lo que hacia era esperar a que se desbloquee haciendo un Sleep(10) en un bucle y cuando este accesible entre al codigo pero aun asi no me funcionaba a veces, empiezo a pensar que es mejor hacerlo con variables como bool como exponemos en este tema:

while (*on_mitm)
	{
		if (control.try_lock())
		{
			//haz cosas
			control.unlock();
//duerme Sleep(TIEMPO);
		}
		Sleep(10);
	}

Los mutex se usan cuando hay datos que son compartidos entre threads y no se pueden modificar en un momento dado del tiempo dado que el valor critico se encuentra en otro thread distinto del actual, entonces se bloquea con un mutex o un semaforo hasta que el estado sea el deseado..

Ejemplo:
5 threads calculando sumas, todos los threads comparten una variable estatica con el resultado final, unos terminan primero y otros terminan despues de computar, cuando termina el ultimo, se suman todos los datos para evitar perdidas.

No necsitas usar try_lock + sleep. Usa lock() y ya. Lock lo pone en la lista de espera. Con try_lock solo mira si está libre.

Lo bueno de usar try_lock en vez de lock es que el recibe un int con el numero de thread que no se pudo bloquear, como para reintentar, o terminar si el thread se va rogue (sin control)

Buenas gracias por las respuestas,

Básicamente usaba el mutex para coordinar varios async que ejecuta un solo thread, que es ejecutado de entre otros thread en el main.

Este thread se encarga de realizar un MITM sobre la red local, mediante ARP Spoofing, lo primero que hace es un escaneo y si hay hosts comienza un async() que los envenena, otro async que cada X tiempo reescanea la red en busca de nuevos hosts y que elimina los que se desconectaron. Tambien otro async se encarga de redirigir los paquetes y filtrarlos para poder obtener los datos de la red, en total son 3. ¿Qué tienen en común?, el adaptador de la interfaz de red, usé mutex para que si hay uno usando ese adaptador no lo usen los otros por se acaso inducía a error pero no sé si llegaría a ocurrir este error.

Estoy hablando de un pcap_t* a través de esa variable envío y recojo paquetes de la red, si la estoy usando en varios procesos, ¿sería necesario un mutex?

Edito: Vaya no sabía eso ivancea, pero creo que lo cambié porque al haber 3 subprocesos usando el mutex, al hacer lock() en 2 a la vez cascaba pues no sabía a cual de los 2 dárselo, pero si lo que dices funciona me ahorraría bastante code.

Saludos.

Extraño.

Lo que sí, los locks del mutex trata de hacerlos solo en los puntos donde realmente los necesitas. Evita poner código de más dentro del mutex. Solo las partes que van a acceder a datos que peligran. Sinó, aumentará el tiempo que los threads están bloqueados, que viene siendo un descenso del rendimiento.