Discussion :

[the_ugly]

Bonjour,

j'utilise la jdk 1.5 et la méthode stop() y est dépréciée. Quelle méthode utiliser pour arrêter mon processus sachant qu'après je veux pouvoir refaire un start() sans générer d'exception?

[the_ugly]

je précise qu'après avoir stoper mon processus, quand je fais un start() dessus j'obtiens une exception : IllegalThreadStateException

[adiGuba]

Salut,

j'utilise la jdk 1.5 et la méthode stop() y est dépréciée. Quelle méthode utiliser pour arrêter mon processus sachant qu'après je veux pouvoir refaire un start() sans générer d'exception?

La méthode start() d'un thread ne peut être appellé qu'une seule fois. Il te faut donc recréer un nouvel objet Thread...

Sinon je te conseille de jeter un coups d'oeil à la FAQ : Gestion des threads ainsi qu'au tutoriel d'Alwin : Programmation des Threads en Java...

a++

[the_ugly]

Merci, ça marche maintenant.

[SEMPERE Benjamin]

Salut,

j'utilise la jdk 1.5 et la méthode stop() y est dépréciée. Quelle méthode utiliser pour arrêter mon processus sachant qu'après je veux pouvoir refaire un start() sans générer d'exception?

La méthode start() d'un thread ne peut être appellé qu'une seule fois. Il te faut donc recréer un nouvel objet Thread...[/url][/b]...

a++

AdiGuba a raison, il faut noter tout de même que la création d'un Thread est assez couteuse.
Ainsi, lorsque tu as beaucoup de Threads à créer il est recommandé d'utiliser un pool de Threads

[bouye]

Et la methode interrupt() alors ?

Moi ca ca bien faire 7~8 ans que j'utilise un truc comme ca dans mes classes :

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
 
  Thread thread;
 
  /** Starts the thread.
   * <BR>The task will start if it is not already running.
   */
  public synchronized void start() {
    if (thread == null) {
      thread = new Thread(runnable, name);
      thread.setPriority(Thread.NORM_PRIORITY);
      thread.start();
    }
  }
 
 
  /** Stops the thread if it is not already running.
   * <BR>The task will be stopped if it is not already stoppped.
   */
  public synchronized void stop() {
    if (thread != null) {
      thread.interrupt();
      thread = null;
      notify();
    }
  }

[the_ugly]

Et la methode interrupt() alors ?

Moi ca ca bien faire 7~8 ans que j'utilise un truc comme ca dans mes classes :

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
 
  Thread thread;
 
  /** Starts the thread.
   * <BR>The task will start if it is not already running.
   */
  public synchronized void start() {
    if (thread == null) {
      thread = new Thread(runnable, name);
      thread.setPriority(Thread.NORM_PRIORITY);
      thread.start();
    }
  }
 
 
  /** Stops the thread if it is not already running.
   * <BR>The task will be stopped if it is not already stoppped.
   */
  public synchronized void stop() {
    if (thread != null) {
      thread.interrupt();
      thread = null;
      notify();
    }
  }

thread.interrupt() et thread=null ne marchaient pas (mon thread était un chrono et il continuaot inéxorablement à avancer dans le temps).

Par contre j'ai utilisé un booléen initialisé à true dans la boucle while et ma méthodes stop consiste à mettre ce booléen à false. Ca marche et c'est joli.

[Gfx]

Fais attention avec un boolean. Si tu y accedes depuis un thread exterieur cela ne marchera pas dans certain cas. Tu dois le declarer volatile.

Personnellement j'ai pour habitude d'utiliser interrupt() et l'affectation a null en interceptant l'exception InterruptedException dans la boucle principale de mon thread (si j'utilise un sleep). Sinon en effet il faut utiliser un truc semblable au tien.

[the_ugly]

volatile, ça veut dire quoi exactement?

[adiGuba]

volatile, ça veut dire quoi exactement?

FAQ : Que signifie le mot-clé volatile ?.

Pour faire bref cela permet de forcer à vérifier la valeur exacte de la variable à chaque fois qu'elle en a besoin... Sinon le compilateur et/ou la JVM d'optimiser le code pour pour des traitements single-thread...

a++

[the_ugly]

ok merci. En gros cela permet de synchroniser l'accès à la varaible. Mais dans mon cas il n'y a qu'un thread qui modifie cette valeur, donc ce n'est pas utile mais je l'ai quand même mis pour m'en souvenir plus tard

[adiGuba]

ok merci. En gros cela permet de synchroniser l'accès à la varaible. Mais dans mon cas il n'y a qu'un thread qui modifie cette valeur, donc ce n'est pas utile mais je l'ai quand même mis pour m'en souvenir plus tard

Non cela ne permet pas de synchronizer (la synchonisation empêche les acces concurrent) ! Cela indique au compilateur et/ou à la JVM que ce champs peut être modifié par différents threads.

Si tu ne met pas volatile tu peux avoir des problèmes à cause des optimisations du compilateur et/ou de la JVM.

Imagine ton thread comme cela :

Code :

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

1
2
3
4
5
6
7
8
9
public boolean running = true;
 
public void run() {
 
	while (running) {
 
		// Traitement ...
	}
}

Et dans ton thread principale tu modifies le champs à false, ce qui devrait arrêter le traitement lors du prochain passage dans le while()...


Or il n'en est rien* car le compilateur et/ou la JVM peut optimiser le code de ta méthode run() en considérant qu'il est mono-thread. Ainsi si dans ton traitement tu ne modifies pas la valeur de running, ils considèrent que la valeur ne peut pas changer et elle ne sera interprété qu'une seule fois (lors de la première entrée dans le while). Du coup le changement de valeur opéré dans l'autre thread passe à la trappe...

a++

* : En fait cela dépend de ta JVM, cela peut marcher comme ca peut boucler à l'infini... donc il est preferable d'utiliser volatile pour être sur du comportement...

[the_ugly]

Même si l'autre Thread appelle une méthode setBoolean cela peut boucler à l'infini?

[adiGuba]

Même si l'autre Thread appelle une méthode setBoolean cela peut boucler à l'infini?

Oui car la JVM peut optimiser les méthodes indépendamment en restant sur une logique mono-thread, donc le code :

Code :

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

1
2
3
4
5
6
7
public void run() {
 
   while (running) {
 
      // Traitement ...
   }
}

Peut être optimisé à la volé en quelque chose de "similaire" à :

Code :

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

1
2
3
4
5
6
7
public void run() {
 
   while (true) {
 
      // Traitement ...
   }
}

Mais comme je l'ai dit cela n'est pas obligatoire et peut varier d'une JVM à l'autre...

Ce type d'optimisation permet d'éviter d'avoir à faire de multiple accès à la valeur d'une variable et peut permettre quelque gain de temps, mais peut provoquer des problèmes en multi-thread d'où l'utilité de volatile...



De plus dans 99% des cas passer par une méthode mutateurs ne change rien car il y a de forte chance qu'elle soit traiter comme une méthode inline à l'exécution, ainsi :

Code :

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

monObject.setBoolean(false);

a de forte chance d'être "remplacer" par :

Code :

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

monObject.booleen = false;

a++