Pourquoi la méthode java.lang.Thread.join () a-t-elle été nommée ainsi?

Question

Quelqu'un sait-il pourquoi la méthode join () membre de la méthode java.lang.Thread a été nommée ainsi? Son javadoc est:

  

Attend la fin de ce fil.

Lorsque la jointure est appelée sur un thread appelant, le thread attend que l'autre meure et continue son exécution. Soi-disant, le fil de discussion mourra également, mais on ne sait toujours pas pourquoi l'auteur a utilisé ce nom.

Answer 1

C'est un nom commun dans les threads - ce n'est pas comme si Java était le premier à l'utiliser. (Par exemple, c’est ce que pthreads utilise également.)

Je suppose que vous pouvez l’imaginer comme si deux personnes se promenaient - vous rejoignez l’autre et marchez jusqu’à ce que vous ayez terminé, avant de revenir à ce que vous faisiez. Cette sorte d'analogie pourrait en être la raison originale, bien que je convienne que ce n'est pas tout à fait intuitif.

Answer 2

Il est nommé de cette façon parce que vous indiquez en principe que le fil d'exécution appelant va attendre pour rejoindre l'état d'exécution indiqué. Elle est également nommée join dans posix et de nombreux autres packages de threads.

Après que cet appel à rejoindre soit renvoyé (sauf s'il a été interrompu), les deux threads d'exécution fonctionnent ensemble à partir de ce point (avec ce thread obtenant la valeur de retour du thread maintenant terminé).

Answer 3

Cela provient d'une modélisation logicielle simultanée lorsque le flux de contrôle se divise en threads simultanés. Plus tard, les deux threads d’exécution vont se rejoindre.

De même, waitToDie () était probablement a) trop long et b) trop morbide.

Answer 4

bon ... ce n’est pas vraiment correct mais j’ai pensé à une "salle d’attente" (ce n’est en fait pas une file d’attente avec une certaine planification comme FIFO, HRRN, etc.) quand un fil ne peut pas continuer et doit attendre sur un autre fil pour finir, il se contente de rejoindre les gars (aka threads) dans la salle d'attente pour devenir actif ensuite ...

Answer 5

Parce que vous attendez un autre thread d'exécution (c'est-à-dire celui sur lequel vous appelez, rejoignez) pour rejoindre (c'est-à-dire die) au thread actuel (c'est-à-dire l'appelant).

Le thread appelant ne meurt pas: il attend simplement que l'autre thread le fasse.

Answer 6

Il s'agit d'une terminologie largement utilisée (en dehors de Java également). Je le prends comme une sorte d’association d’un fil à un autre. Je pense que Thread.Associate () aurait pu être une meilleure option, mais Join () n’est pas mauvais non plus.