Discussion :

[FFF]

bonsoir,

J'ai une classe principale possédant une méthode pour la fermeture du programme mutli-thread. La méthode que j'utilise pour fermer l'application est de terminer brusquement un thread pour qu'il passe de l'état "vivant" à l'état "mort" tout en m'assurant qu'aucune donnée ne sera perdue (ce qui m'empêche de faire un System.exit() tout court). La méthode de fermeture de ma classe principale du programme surveille alors l'état de ce thread et termine par un exit :

Code :

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

1
2
3
4
        while(monitor.isAlive()) {
            System.out.println("On attend la fermeture du monitor...");
        }
        System.exit(1);

Ne sachant pas quoi mettre dans la boucle while() j'ai mis un pti texte.

Cette méthode n'est pas satisfaisante puisqu'elle monopolise le proc (la souris fait des saccades). Que me conseillez vous de faire pour empêcher ceci ?

Merci.

[jcodeunpeu]

Salut,
oui y'a des chance que le proc hallucine, imagine si pendant ce temps il doit écrire dans un fichiers quelques dizaines de milliers de lignes ...
je propose donc de remplacer :

Code :

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

1
2
3
4
5
 
while(monitor.isAlive()) { 
  System.out.println("On attend la fermeture du monitor..."); 
} 
System.exit(1);

par :

Code :

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

1
2
3
4
5
6
7
8
 
while(monitor.isAlive()) { 
  try{
    Thread.sleep(200);
  }catch(InterruptedException ie){
    System.out.println("On attend plus la fermeture du monitor..."); 
  }
}

étant entendu que par ailleurs il y à une condition genre while(running){}
(dans run() ) et ailleurs encore une autre if(fini){running = false)} ...
il y a aussi la synchronisation pour çà, à voir .
A++

[FFF]

ok merci, ça me conviens tout à fait !!! Je me rappelais plus que sleep était une méthode statique et que l'on pouvait l'utiliser comme cela ...

étant entendu que par ailleurs il y a une condition genre while(running){}
(dans run() ) et ailleurs encore une autre if(fini){running = false)} ...

of course !!

il y a aussi la synchronisation pour çà, à voir .

Je pense que tu fais allusion à une méthode synchronisée possédant un notify() à la fin ? Ceci m'obligerait à faire une boucle infinie me semble-t-il dans ma classe principale pour toute la durée de fonctionnement de l'application pour surveiller les verroux de fermeture... non ? alors qu'ici je le fais seulement à le fermeture...
je pense qu'il y a plus élégant que ma méthode, mais bon n'ayant pas beaucoup de thread, je trouve cela assez simple et efficace, mais bon je suis ouvert à toutes suggestions...

[adiGuba]

Salut,

oui y'a des chance que le proc hallucine, imagine si pendant ce temps il doit écrire dans un fichiers quelques dizaines de milliers de lignes ...

En effet, et même sans afficher de ligne cela reste très lourd car le processus fera un nombre incalculable d'appel à la méthode isAlive()...
Ce type d'attente s'appelle une attente "active" puisque le processeur reste actif pendant tous le temps de l'attente...


Il est donc préférable de faire "dormir" le processeur pendant cette attente : c'est ce qu'on appelle l'attente "passive"...
La solution de jcodeunpeu peut faire l'affaire, en réglant le temps du sleep() selon la durée de ton thread afin de ne pas réveiller le processeur trop souvent...

il y a aussi la synchronisation pour çà, à voir .

Oui et je pense que c'est même plus simple...

Il suffit de synchronizer la méthode run() sur l'instance du Thread dans lequel elle est lancé, par exemple :

Code :

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

1
2
3
4
5
6
7
public void run() {
	synchronized(Thread.currentThread()) {
 
		// Traitement du thread ici
 
	}
}

Du coups l'attente de la fin du thread se fait de la sorte :

Code :

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

1
2
3
4
5
while (monitor.isAlive()) {
	synchronized(monitor) {
		// empty
	}
}

Le bloc synchronized à l'intérieur du while() endormira le thread principal pour ne le reveiller qu'a la fin du bloc synchronized de la méthode run().
Le while() reste neccessaire pour gérer le petit labs de temps entre le démarrage du thread et l'entrée dans le bloc synchronized, ainsi que la sortie du bloc synchronized et la fin réelle du thread...


Sinon avec Java 5.0 la nouvelle API de concurrence permet également de faire quelque chose de similaire... Cf ce message : Question d'implémentation: boucle active


a++

[jcodeunpeu]

Bonsoir adiGuba,
merci pour ce jour nouveau porté sur le probleme, une pure merveille, trés instructif la synchronisation du thread courant, je n'y pensais pas et c'est trés élégant ... merci encore.
A++
ps : si tu peux jeter un p'tit coup d'oeil à mon post si tu as le temps :
[Process][Localisation ...] merci d'avance.

[FFF]

Merci pour vos réponses !!

Du coups l'attente de la fin du thread se fait de la sorte :

Code :

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

1
2
3
4
5
while (monitor.isAlive()) {
	synchronized(monitor) {
		// empty
	}
}

Pour ne pas répéter ce qu'a dit jcodeunpeu je te demanderais simplement un éclaircissement (si possible ?) c'est bien la fin de l'exécution de la méthode synchronized du run() (et non le run() en entier) qui fait que synchronized(monitor) peut être exécuté ?

Merci pour la méthode !

[jcodeunpeu]

Bonjour FFF,
ce que je comprend, c'est qu'il est fait de ce Thread (courant) un objet synchronized, tout entier, la méthode run fonctionne de toute façon un peu comme le main d'une classe, tant que toutes les instructions du corps ne sont pas exécutées , il continue.
le point de synchronisé le thread tout entier, force cet objet(Thread) à notifier( peut être de façon implicite) la fin de sa propre exécution, information qui est attendu de l'autre côté par un autre bloc synchronisé
ayant pour cible cet objet (les méthodes synchronisées vont de paire, une qui dit quand l'objet est prêt, une qui attend que celui-ci le soi :
comme adiGuba le dit : un simple if(monitor.isAlive()) ne suffit pas, car ...
enfin je peut pas paraphraser adiGuba, çà sera moins clair, ce qui peut t'éclairer, c'est qu' un objet l'est toujours 2 fois:
en notification d'un résultat et en attente de ce résultat.
et qu'une méthode synchronizée l'est en rapport à une autre, elle peuvent communiquer parcequ'elles sont toutes deux synchronized...
en bref je dirai que run() n'est pas synchronisée, ne peut pas l'être d'ailleurs, puisque c'est juste un déclencheur, c'est bien l'objet, et non une méthode, qui est synchronized :
synchronized(Thread.currentThread()){} rend le thread courant synchronisé, ce qui signifie que ailleurs, une instruction
synchronized(monitor){} stop net l'exécution du code qui suit à cet endroit, et qui est un nouvel appel à isAlive(). Tant que monitor n'a pas reçu le message de la part du premier bloc (ce message est en somme "jesuis arrivé à la fin de moi-même", c'est comme çà; une fois fini, un nouveau passage dans while est possible du coup, qui renvoie maintenant faux ... j'espère que je me suis pas trop emmélé les pinceaux../
A++

[FFF]

Autre solution :
utiliser la méthode join(int msec) de la classe Thread permettant d'attendre la mort d'un thread pendant msec millisecondes (0 pour attendre indéfiniment), c'est la solution que j'ai retenue et ça à l'air de bien fonctionner.

[jcodeunpeu]

salut,
mais cela sous-entend de connaître le délai d'attente avec précision + éventuellement petite marge ... ????

[adiGuba]

salut,
mais cela sous-entend de connaître le délai d'attente avec précision + éventuellement petite marge ... ????

Non justement... join(0) ou join() tout court qui est équivalent) attendra la fin du thread sans délai d'attente...

a++

[jcodeunpeu]

oui oui, pour le cas choisit join(0) ....

[alheim]

dites donc ca devrait être un tuto ca ?
"Comment synchronizer le thread principal avec un ou plusieurs thread secondaires de manière élégante "

Merci messieurs pour la lecon.