Discussion :

[Serniratte]

Bonjour,

Dans le cadre de mon projet il m'est nécessaire de créer un thread, donc j'ai écris ce code mais voila un petit soucis, si je crée par exemple un thread t, quand j'appelle la méthode t.start(); le thread ce lance correctement mais impossible de le stoppe avec la méthode t.arreter(); si quelqu'un à une idée

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
package msxy05.jeuvie;
 
public class MonThread extends Thread{
	private Monde monde;
	private MonCanvas canva;
	private boolean actif = true;
 
	public MonThread(Monde monde,MonCanvas canva){
		this.monde=monde;
		this.canva=canva;	
	}
 
	 public void run() {
		 while(actif){
			 this.monde.Nextgeneration();
			 this.canva.paintAll(this.canva.getGraphics());
			  }
		  }	  
	 public void arreter() {
		 actif=false;
	 }
}

Cordialement
Serni

ps: j'ai poste dans cette rubrique je sais pas trop si c'est la mieux indiqué :/

[Mobius]

Je t'invite a consulter la javadoc de la méthode Thread.stop qui est déprécié et donc qui ne doit pas être utilisé. Cepedant, la doc donne toutes les infos dont tu as besoin.

Tu peux aussi regarder ce post (c'est le premier lien quand tu cherche "Thread stop" dans google)


EDIT: j'ai lu un peu trop rapidement ton post et me suis rendu compte que je ne répondait pas a ta question.
J'ai donc repris ton code qui fonctionne très bien chez moi.
Quel est exactement ton problème ?

[Serniratte]

Merci de la réponse,

quand j'appelle "arreter();" le thread continue de fonctionner voila mon problème

[Mobius]

si tu prend ce code (tu remarqueras que c'est le même que le tiens a peu de chose prés) :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
package thread;
 
public class StartStop {
 
	private final static Object LOCK = new Object();
 
	private final static void attendre(long timeout) {
		synchronized (LOCK) {
			try {
				LOCK.wait(timeout);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		}
	}
 
	public static class MonThread extends Thread {
		private boolean actif = true;
 
		public MonThread() {
		}
 
		public void run() {
			while (actif) {
				System.out.println("actif");
				attendre(1000);
			}
			System.out.println("inactif");
		}
 
		public void arreter() {
			actif = false;
		}
	}
 
	public static void main(String[] args) {
		System.out.println("debut");
		MonThread t = new MonThread();
		t.start();
		attendre(2000);
		t.arreter();
		try {
			t.join();
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
		attendre(1000);
		System.out.println("fin");
	}
}

Ca fonctionne bien correctement.
A mon avis, le problème ne vient de ton algo mais de l'interface graphique qu'il faut fermer explicitement.

[Serniratte]

Je ne comprend pas trop le fait de fermer mon "interface graphique explicitement"

pour expliquer le contexte mon thread me sert à lancer la simulation de ma grille qui ce trouve sur mon interface et je veux simplement stope la simulation de la grille (donc le thread) mais pas fermer l'interface

[publicStaticVoidMain]

Juste une question, c'est cmt tu arretes ton thread?
Est ce que t'as un bouton ou un endroit explicite dans ton appli qui dit "arreter simulation par exemple"?

[Mobius]

je veux simplement stope la simulation de la grille (donc le thread) mais pas fermer l'interface

+1

As tu essayé de débuguer ton application (en mode pas à pas) pour voir pour quel raison ton thread n'est pas arrété (il n'y a aucune raison qu'il continue de tourner)
Peut être que tu n'appel pas la méthode arreter sur le bon thread ? (je ne vois pas pouquoi mais bon...) Es tu sur que la méthode arreter est appelée correctement ?

[publicStaticVoidMain]

Je ne comprend pas trop le fait de fermer mon "interface graphique explicitement"

pour expliquer le contexte mon thread me sert à lancer la simulation de ma grille qui ce trouve sur mon interface et je veux simplement stope la simulation de la grille (donc le thread) mais pas fermer l'interface

POur arreter ton thread, il faut que la variable actif soit vue / appelée de l'extérieur. En gros, il faut qu'elle soit publique.
Donc, il faut la protéger avec des sémaphores

[Serniratte]

Alors en fait mon thread s'arrête effectivement avec l'appuie sur un bouton stop.

J'ai essayé un débugage la méthode est bien appelé est le boolean est bien modifié (il passe bien de "true" a "false" grâce la méthode arreter)

Pour ce qui est des sémaphores ca dépasse mes compétences la O_o

[Mobius]

Alors en fait mon thread s'arrête effectivement avec l'appuie sur un bouton stop.

Si le thread s'arrête, quel est le problème ?

[Uther]

Essaie aussi de déclarer la variable actif comme private volatile boolean actif = true;

Sinon, il est possible que pour le code suivant:

Code :

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

1
2
3
4
while (actif) {
	System.out.println("actif");
	attendre(1000);
}

le compilateur soit tenté d'optimiser en supprimant le test de la condition de la boucle, vu que la variable actif ne peux pas être modifié par le thread en court.
En déclarant actif "volatile" tu empêches, ce type d'optimisation.

[Serniratte]

merci pour la réponse mais j'ai déjà essayé le volatile ca change rien :/

Si le thread s'arrête, quel est le problème ?

en fait ce que je voulais dire c'est qu'il doit s'arrêter comme ca mais justement ca ne fonctionne pas d'où le problème

[Cazouille]

Ce code est appelé par une interface graphique. Un bouton A appelle la méthode "start" du thread et un bouton B appelle la méthode "arreter" qui change donc juste la variable de la classe.

On a constaté que même si l'on modifie la variable en question, on dirait que le thread s'en cogne le coquillât et continue son affaire.

Nous ne voulons ici pas faire appel à la méthode "stop", à la limite, un "sleep" mais nous n'en sommes pas là. Le seul hic, c'est qu'on ne comprend pas pourquoi le thread continue sa tambouille et ne s'arrête pas lorsque l'on modifie le booléen à "false".

PS : j'ai jeté un œil à la globalité de son code et je ne comprends pas non plus pourquoi ça merdouille.

[fr1man]

Ca vient de tes instructions qui bloquent le thread : this.monde.Nextgeneration();
this.canva.paintAll(this.canva.getGraphics());

J'imagine que ces deux instructions prennent du temps et du coup tu ne reviens jamais effectuer le test de sortie while(actif).

[Cazouille]

Même si ça prend du temps à s'exécuter, le test doit tout de même être fait puisque le thread est toujours actif, non ? Je ne pense pas que ça prenne plus de 30 secondes à rafraîchir une interface graphique, sinon, je ne comprends pas comment tournent les IHM java :s

[fr1man]

Si ton this.monde.Nextgeneration(); prend beaucoup de temps, tu n'en sortiras jamais (enfin si mais dans longtemps), et donc même si la variable de sortie du thread est modifiée tu n'effectueras jamais le test de sortie.
Tu comprends ?

[publicStaticVoidMain]

Même si ça prend du temps à s'exécuter, le test doit tout de même être fait puisque le thread est toujours actif, non ? Je ne pense pas que ça prenne plus de 30 secondes à rafraîchir une interface graphique, sinon, je ne comprends pas comment tournent les IHM java :s

J'imagine que tu fais du Swing et il faut savoir que Swing utilise son propre thread pour l'affichage. Donc il est fortement conseillé de lancer Swing dans un thread à part en faisant ca :

Code :

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

1
2
3
4
5
6
 
SwingUtilities.invokeLater(new Runnable() {
    public void run() {
        // tu crées ton IHM ici
    }
});

Bah le probleme avec ton code est que tu veux arreter le thread MonThread (en faisant à mon quelque part thread.arreter()) tandis que le thread appelant n'a pas la main. Donc du coup, ca bloque.

[Cazouille]

En gros, pour vous, le thread de l'IHM empêche le thread implémenté de s'exécuter correctement ? (J'avoue, ça me laisse perplexe, je ne me rappelle pas avoir eu ce genre de problème)

Java est bien censé lui-même gérer ses thread internes, non ?

Alors si l'on crée un thread "manuellement", il est censé être prioritaire (je ne fais que supputer, j'entre sur un terrain miné car je n'ai jamais poussé le problème jusque-là ^^ donc faites-moi savoir si je dis des conneries)

[publicStaticVoidMain]

En gros, pour vous, le thread de l'IHM empêche le thread implémenté de s'exécuter correctement ? (J'avoue, ça me laisse perplexe, je ne me rappelle pas avoir eu ce genre de problème)

C'est un problème classique que l'on rencontre lorsqu'on utilise des thread dans son programme.
Et ce n'est pas le thread de l'IHM qui est en cause mais le thread MonThread que t'a créé parce que le thread appelant (la partie du code ou tu appelles thread.arreter()) n'a pas la main et il ne peut pas s'éxécuter. Quand tu lances un programme qui contient des threads, tu n'as aucune garantie quant à l'ordre d'exécution des threads entre eux. Ce n'est pas parce que le thread A est créé avant les threads B et C qu'il s'exécutera avant eux. Une exécution possible est B, A , C ou C B A, etc

Java est bien censé lui-même gérer ses thread internes, non ?

Vu les raisons que j'ai évoquées, c'est au programmeur de gérer l'exécution de ses threads.

Alors si l'on crée un thread "manuellement", il est censé être prioritaire (je ne fais que supputer, j'entre sur un terrain miné car je n'ai jamais poussé le problème jusque-là ^^ donc faites-moi savoir si je dis des conneries)

Quand tu crées un thread, sa priorité est égale à celle qui l'a créé.

[Cazouille]

O.K. Merci pour tes éclaircissements (et aux autres aussi )
C'est bien Swing qui est utilisé, au passage.
Je regarderai de nouveau avec l'auteur du topic et il vous tiendra au courant.