Problème gestion threads

[sandrecarpe]

Bonjour à tous
J'ai un programme qui tourne sur raspberry pi 2 dans le but de gérer mon terrarium grâce à différents capteurs.
J'ai créé un thread pour chaque capteurs, ils sont initialisés dans le constructeur de la classe Terrarium.
Comme le programme repose sur la lecture des capteurs, j'appelle la méthode join() sur chaque thread mais quand j'appelle les join par la méthode Terrarium::loop(), le programme cesse de fonctionner brutalement, il semblerait juste avant l'appelle de loop(). En revanche si je mets les join() dans le constructeur il n'y a pas de soucis.

Terrarium.cpp

Terrarium::Terrarium() : 
	_mf_eclairage(false), _mf_brumisateur(false), _dht(PIN_DHT22), _lcd(0x27), _log("/var/www/terrarium.log"),
	_threadDht22(0),
	_threadHumiditeSol(0)
{

	_dht.setListeners(this);
	_lcd.init();

	
	
	//on creer un thread pour recevoir les infos de la sonde dht22
	_threadDht22 = new thread(&Terrarium::thread_watching_dht22, this);
	
	//on creer un thread pour recevoir les infos du capteur d'humidite du sol
	_threadHumiditeSol = new thread(&Terrarium::thread_watching_humidite_sol, this);



	//on défini les heures d'allumage et d'extinction de l'éclairage
	time_t now = time(0);

	struct tm today;
	today = *localtime(&now);

	struct tm soirStart;
	soirStart = *localtime(&now);
	soirStart.tm_hour = 18;
	soirStart.tm_min = 30;
	soirStart.tm_sec = 0;
	if(soirStart.tm_hour < today.tm_hour)
	{
		soirStart.tm_mday++;
	}

	struct tm soirEnd;
	soirEnd = *localtime(&now);
	soirEnd.tm_hour = 22;
	soirEnd.tm_min = 0;
	soirEnd.tm_sec = 0;
	if(soirEnd.tm_hour < today.tm_hour)
	{
		soirEnd.tm_mday++;
	}

	struct tm matinEnd;
	matinEnd = *localtime(&now);
	matinEnd.tm_hour = 9;
	matinEnd.tm_min = 0;
	matinEnd.tm_sec = 0;
	if(matinEnd.tm_hour < today.tm_hour)
	{
		matinEnd.tm_mday++;
	}

	struct tm matinStart;
	matinStart = *localtime(&now);
	matinStart.tm_hour = 6;
	matinStart.tm_min = 30;
	matinStart.tm_sec = 0;
	if(matinStart.tm_hour < today.tm_hour)
	{
		matinStart.tm_mday++;
	}

	//on lance le thread qui gère l'éclairage
	//Eclairage eclairage(&matinStart, &matinEnd, &soirStart, &soirEnd, this);
	//eclairage.start();
	Eclairage eclairage;
	eclairage.initCrontab();
	eclairage.deleteCrontab();
	eclairage.addCronTask(&soirStart, true);
	eclairage.addCronTask(&soirEnd, false);
	eclairage.addCronTask(&matinStart, true);
	eclairage.addCronTask(&matinEnd, false);
	eclairage.validCrontab();

	/*_threadDht22->join();
	_threadHumiditeSol->join();*/

}

void Terrarium::loop()
{
	cout << "boucle thread" << endl;
        _threadDht22->join();
 	_threadHumiditeSol->join();
	
}

main.cpp

//includes...

Terrarium *terrarium;

int main(int argc, char *argv[])
{

	signal(SIGINT, onAbort);

        /*

               ............

       */

	terrarium = new Terrarium();
	terrarium->loop();

	while(true); //boucle infini


	return 0;
}

En espérant avoir été clair, je vous remercie d'avance pour votre aide
-----

[invite29be2dfb]

Bonjour
On peut supposer qu'il y a un problème de ressource, disponible dans un cas, pas dans l'autre.
Il serait intéressant de savoir quel «join» (ou quelle thread) ne fonctionne pas. Les deux?

[polo974]

ce

    while(true); //boucle infini

entraîne un cpu à 100%...

les join() avant évitent d'arriver à cette boucle de la mort qui tue.


en passant, Terrarium::loop() n'a rien d'une boucle. il vaudrait mieux éviter ce genre de nommage...

et au final, à quoi sert-il d'avoir 3 threads dont le principal inutile qui ne fait que consommer de la ressource ? ? ?
il suffisait de lancer un thread et d’exécuter la seconde tâche dans le thread principal.

[sandrecarpe]

Finalement j'ai trouvé le problème , il était dans le destructeur de Eclairage

ce
Code:
while(true); //boucle infini
entraîne un cpu à 100%...

les join() avant évitent d'arriver à cette boucle de la mort qui tue.

Et un join() ne fait-il pas une boucle de la mort en interne ?

C'est vrai que Terrarium::loop() n'est pas le meilleur nom qu'on puisse donner à la fonction mais j'étais en manque d'inspiration sur le coup.
J'aurais pu donner la gestion du dernier capteur au thread principale, (il n'y a pas ici la totalité du programme) mais il tourne pas dans le vent il est occupé a d'autre tâche quand même. Et cette façon de faire (je trouve) me laisse libre de modifier et d'ajouter des fonctionnalités sans me casser la tête (les threads restent dans leur coin et moi dans le miens )

[A voir en vidéo sur Futura]

[invite29be2dfb]

Et un join() ne fait-il pas une boucle de la mort en interne ?

Non, le thread appelant est suspendu. D'ailleurs, je crois que si les 2 autres threads ne se terminent pas, la boucle while n'est jamais exécutée.

[sandrecarpe]

D'ailleurs, je crois que si les 2 autres threads ne se terminent pas, la boucle while n'est jamais exécutée.

Tout à fait !

Merci pour ta réponse

[polo974]

....
J'aurais pu donner la gestion du dernier capteur au thread principale, (il n'y a pas ici la totalité du programme) mais il tourne pas dans le vent il est occupé a d'autre tâche quand même.

Enfin, là, il bloquait sur le while à 100% de cpu (sans les join)...
Quand il n'y a rien à faire même momentanément, il vaut mieux ajouter un sleep(1) ou un usleep si on veut descendre sous la seconde.
Idem dans les gestions d'erreurs, quand on n'est pas trop pressé ni regardant sur la raison...
Sinon, on se retrouve comme actuellement avec certaines applis qui bouffent 100% de cpu en attendant que le réseau soit dispo.
(ouais, et il y en a de plus en plus de ces me..es dans les distris linux ...)

Et cette façon de faire (je trouve) me laisse libre de modifier et d'ajouter des fonctionnalités sans me casser la tête (les threads restent dans leur coin et moi dans le miens )

vouiiiii, mais pas avec un while(1); préfère un while(1) sleep(1);

regarde select() ou epoll(), c'est sympa aussi...

[sandrecarpe]

Bonsoir,
Merci pour ta réponse, maintenant les join() sont là pas de soucis.
Les 2 fonctions que tu m'as envoyé peuvent être pratique mais de quelle façon tu pensais que je pouvais les utiliser ?

[polo974]

Bonsoir,
Merci pour ta réponse, maintenant les join() sont là pas de soucis.

Oui, mais quand les 2 threads finissent, tu entres dans la boucle infernale...
il faut une tempo pour calmer le jeu, ou bien sortir du programme...

Les 2 fonctions que tu m'as envoyé peuvent être pratique mais de quelle façon tu pensais que je pouvais les utiliser ?

ces fonctions permettent de mettre un thread en attente sur plusieurs sources possibles (des attentes de lecture sur des flux de données en général) et avec un timeout.
c'est le truc qui évite de lancer des threads dans tous les sens.
mais on ne peut plus écrire le programme comme un long fleuve tranquille en le bloquant à chaque échange vu que ça risque de bouger de l'autre coté...
il faut donc découper les tâches et garder un état courant de chaque tâche pour pouvoir passer de l'une à l'autre à chaque fois qu'il n'y a rien à faire dans la tâche courante.

[sandrecarpe]

Bien-sûr j'ai enlevé la boucle infini maintenant qu'il y a les join() !
D'accord d'accord, mais ça m'a l'air tout de même pas si évident !
Merci pour ta réponse