Fonction boost::thread::join() et indépendance d'un thread

**ptyxs** · 05/02/2011, 16h38

Bonjour
je débute plus ou moins en matière de Boost et de threads.
J'attaque par le chapitre 6 Multithreading du livre de Boris Schäling (voir http://en.highscore.de/cpp/boost/index.html ).
A la sous-section 6.2, l'auteur écrit ceci :
As seen in the above example, a particular thread can be accessed via a variable such as t in order to e.g. wait for its termination using the join() method. However, the thread will continue to execute even if t loses its scope and is destroyed. A thread always binds to a variable of type boost::thread in the beginning, but once created, depends no longer on it.
Son exemple est le programme suivant ou un thread affiche 5 entiers à l'écran :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include <boost/thread.hpp> 
#include <iostream> 
#include <fstream>
 
void wait(int seconds) 
{ 
  boost::this_thread::sleep(boost::posix_time::seconds(seconds)); 
} 
 
void thread() 
{ 
  for (int i = 0; i < 5; ++i) 
  { 
    wait(1); 
    std::cout << i << std::endl;
  } 
} 
 
int main() 
{ 
  boost::thread t(thread); 
  t.join();
}

J'avais donc cru comprendre que la ligne finale du main

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

t.join();

était en quelque sorte ici facultative.
Toutefois si je la commente, le programme résultant n'affiche plus les entiers en console.
Et si je remplace le contenu de la fonction thread() de façon à le rendre indépendant d'un affichage console (par exemple en effectuant simplement la création d'un fichier), il en va de même : si la ligne t.join(); est commentée pas de création de fichier...
Du coup, je ne comprends plus très bien, d'après l'auteur le thread devrait continuer à s'exécuter indépendamment, même après la fin du main, mais ça ne semble pas être le cas. Ce que dit l'auteur est-il inexact ?

**vikki** · 05/02/2011, 18h58

Salut,
La citation que tu donnes est assez claire. Un objet de type boost::thread représente bien le thread créé et permet dans une certaine mesure d'interagir avec. Si l'objet boost::thread est détruit, le thread continue à s'exécuter mais tu n'y auras plus accès (le thread est alors dit "détaché"). La méthode join() retourne lorsque le thread termine son exécution, elle est donc indispensable dans code d'exemple. En effet, peut importe le nombre de thread ou l'état de leur exécution, quitter la fonction main() veut toujours dire la fin de ton programme et de TOUS les thread créés par celui ci.

**ptyxs** · 05/02/2011, 19h33

Bon, merci, je retiens donc ceci :

Envoyé par vikki

peu importe le nombre de threads ou l'état de leur exécution, quitter la fonction main() veut toujours dire la fin de ton programme et de TOUS les thread créés par celui-ci.

La phrase :
However, the thread will continue to execute even if t loses its scope and is destroyed.
semblait indiquer qu'après la fin du thread main, où justement le thread t 'loses its scope and is destroyed' le thread t pouvait continuer à s'exécuter.

Mais en fait le thread main est le thread 'leader' du groupe de threads et quand le 'leader' est tué ses fils sont tués aussi, c'est ça ?

**vikki** · 05/02/2011, 19h48

Mais en fait le thread main est le thread 'leader' du groupe de threads et quand le 'leader' est tué ses fils sont tués aussi, c'est ça ?

La fonction main est le point d'entrée du programme, elle est appelée par le système d'exploitation à l"exécution du binaire. Quitter cette fonction signifie toujours la fin de l'exécution du programme et de tous les processus fils.

**Emmanuel Deloget** · 05/02/2011, 20h06

De manière intéressante, le detach() optionnel sous boost deviendra obligatoire en C++0x : une thread qui est joinable quand elle entre dans son destructeur va provoquer un appel à std::terminate(). Du coup le comportement du programme sera on ne peut plus clair.

**ptyxs** · 05/02/2011, 20h30

Oui, évidemment, tous les threads partagent un même espace mémoire alloué par le système d'exploitation et la fin du main() signifie la libération de cette zone et donc la fin des threads qui s'y meuvent...

**vikki** · 05/02/2011, 21h43

De manière intéressante, le detach() optionnel sous boost deviendra obligatoire en C++0x : une thread qui est joinable quand elle entre dans son destructeur va provoquer un appel à std::terminate(). Du coup le comportement du programme sera on ne peut plus clair.

Si j'ai bien compris, ca va obliger à modifier pas mal de code

. A moins qu'il suffise d'un set_terminate avec un terminate_handler qui ne fait rien (j'ai du mal à voir les effets de bord)?

**Emmanuel Deloget** · 05/02/2011, 22h55

Envoyé par vikki

Si j'ai bien compris, ca va obliger à modifier pas mal de code

. A moins qu'il suffise d'un set_terminate avec un terminate_handler qui ne fait rien (j'ai du mal à voir les effets de bord)?

Modifier le code, modifier le code... C'est vite dit : il n'y a aucun code qui utilise std::thread a l'heure actuel (outre le code expérimental basé sur l'implémentation fournie dans les versions récentes de g++). Celui qui veut passer les thread de boost à std devra de toute façon modifier le code, donc l'impact supplémentaire n'est pas forcément très important.

Le terminate handler est censé ne jamais terminer (en fait, un terminate handler peut juste afficher un diagnostique et quitter le programme ; la norme dit que la fonction ne peut pas retourner le contrôle à l'appelant. Ceci dit, g++ implemente le std::terminate ainsi : (dans le principe))

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
namespace std
{
  void terminate()
  {
    if (__terminate_handler) __terminate_handler();
    exit(...);
  }
}

Du coup, même si le terminate handler ne fait pas ce qui est souhaitable vis à vis de la norme, le programme s'arrête quand même. Au niveau de la norme, il faudrait faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
namespace std
{
  void terminate()
  {
    if (__terminate_handler) __terminate_handler();
    else exit(...);
  }
}

Ce qui forcerait le code de __terminate_handler() a quitter le programme, sous peine d'avoir un programme mal formé.

**vikki** · 05/02/2011, 23h06

Concernant le passage au std::thread, je pensais faire un simple CTRL+F -> remplacer boost::thread avec std::thread (pareil sur les header) mais j'exagère, il n'y a pas mort d'homme. Juste bien penser, dès maintenant, à rajouter le detach() si approprié.

Mais que fait on sur ce forum un samedi soir

?

**ptyxs** · 06/02/2011, 14h23

Pour en revenir à ma question initiale et à la réponse donnée plus haut :

Envoyé par vikki

La fonction main est le point d'entrée du programme, elle est appelée par le système d'exploitation à l"exécution du binaire. Quitter cette fonction signifie toujours la fin de l'exécution du programme et de tous les processus fils.

il semblerait que ce soit un peu moins absolu, d'après ce que je vois ici :
https://computing.llnl.gov/tutorials/pthreads/#Joining

If main() finishes before the threads it has created, and exits with pthread_exit(), the other threads will continue to execute. Otherwise, they will be automatically terminated when main() finishes.

**vikki** · 06/02/2011, 15h19

Es tu sûr que pthread_exit() n'est pas appelé en fin de main justement pour éviter de quitter celui-ci tant que tous les processus fils ne sont pas terminés?

**ptyxs** · 06/02/2011, 15h45

Je ne suis sûr de rien, sinon je n'aurais pas ouvert ce fil...

Cela dit ce que tu suggères est peut-être vrai, je n'en sais rien - encore une fois comme dit plus haut, je suis débutant en matière de threads - mais si c'est vrai, ça signifie que le texte cité n'est pas vraiment correct ou alors au mieux très mal rédigé...

Ce texte, dit en effet :
"Si main() se termine avant les threads qu'il a créés et s'achève avec un pthread_exit(), alors les autres threads continueront leur exécution. S'il n'en est pas ainsi, ils se termineront automatiquement quand main() finira."
ce qui signifie pour le lecteur normalement constitué sans connaissance préalable du sujet que dans certaines circonstances main() peut se terminer avant des threads qu'il a créés...
Quelqu'un comme toi qui "connait l'histoire" rectifie de lui-même et ne prête pas même attention à la bizarrerie de la formulation.

**vikki** · 06/02/2011, 16h29

Quelqu'un comme toi qui "connait l'histoire" rectifie de lui-même et ne prête pas même attention à la bizarrerie de la formulation.
Aujourd'hui 15h19

Malheureusement je connais pas si bien l'histoire que ca et ma question était une vraie question

.

Une autre description de pthread_exit() glanée sur le web:

Terminating the initial thread by calling this subroutine does not terminate the process, it just terminates the initial thread. However, if all the threads in the process are terminated, the process is terminated by implicitly calling the exit subroutine with a return code of 0 if the last thread is detached, or 1 otherwise.

C'est un peu ambigu (de mon point de vue), quitte-on la fonction main ou non? Je vais continuer à regarder sur la toile.

**Emmanuel Deloget** · 06/02/2011, 21h42

Ce n'est pas si ambigu que ça : ça termine la thread principale avant la fin de main() ; si d'autres thread sont en cours d'exécutions, elles continuent de s'exécuter puisque le processus existe toujours. Sinon, le processus se termine, et pthread_exit() renseigne la valeur de retour du programme.

Il faut que je vérifie std::thread, parce que ce point particulier ne me semble pas être traités.

**ptyxs** · 07/02/2011, 10h46

Tu mets thread au féminin : idiosyncrasie ou usage général ? J'espère que ce n'est pas du pur politiquement correct...

**Goten** · 07/02/2011, 12h08

une tâche, un thread. J'avais jamais vu au féminin jusque là.

**ptyxs** · 07/02/2011, 12h12

un fil un thread, je voyais ça comme ça...

**Emmanuel Deloget** · 07/02/2011, 15h02

Envoyé par ptyxs

Tu mets thread au féminin : idiosyncrasie ou usage général ? J'espère que ce n'est pas du pur politiquement correct...

C'est ce qu'on appelle une sale habitude, c'est tout

Ca fait 15 ans que j'emploie le féminin, donc ça risque d'être compliqué à abandonner.

En anglais, thread est comme tous les objets, du genre indéfini (ni féminin, ni masculin). Je ne penses pas avoir faux en le mettant au féminin, même si les tenants du masculin ont eux aussi tout à fait raison (un fil). Disons que pour ma part, ça me convient.

Le vocable tâche n'est pas bijectif avec thread (puisqu'une tâche peut être un processus). Cf. http://fr.wikipedia.org/wiki/Thread_(informatique) pour les différents noms possibles (wikipedia met thread au masculin ; je peux tenter de réformer mon esprit si vous le souhaitez vraiment très fort

).