Arrêter 4 threads temporairement

Version imprimable

18/10/2006, 21h23
crocodile

Arrêter 4 threads temporairement

Bonjour,

J'ai une classe X qui etends la classe Thread. J'instancie 4 objets de ma classe X dont les threads principaux sont actifs.

Lors d'un évenement Y, j'aimerais bloquer les 4 Threads pour les faire redémarrer plus tard.

Quelqu'un peut-il m'aider ?

Merci d'avance.
19/10/2006, 01h10
Mister Nono

Par exemple : les threads lisent un Boolean et s'arrêtent quand celui-ci change d'état.

Pour l'arrêt :

return;
OU
sleep(xxxx);
OU
wait(xxxx);
OU
...

Nota : Parfois le système d'exploitation (que je ne citerais pas :aie:) plante, et tous les petits threads de la machine s'arrêtent tout seuls. :mouarf:

A+ ;)

Code:

1
2
3
4
5
6
7
8
9
10
 
 
while(!stopped){
   if(paused){
      this.yield(); // Cela donne la main aux autres threads.
   }
   else{
      // Les traitements lorsque le thread n'est pas en pause.
   }
}

19/10/2006, 13h15
professeur shadoko

sauf erreur de ma part ça ne marche pas
(problème des copies privées de la mémoire par les threads, voir les explications sur volatile)
est-ce que le code mis ici http://www.developpez.net/forums/sho...d.php?t=221981 dans le post 15 te conviendrait?
19/10/2006, 14h21
Kikito

J'ai toujours fait comme iohack et jamais eû de problèmes, qu'est ce qui ne marche pas ?
19/10/2006, 19h41
®om
Citation:
Envoyé par iohack

Code:

1 2 3 4 5 6 7 8 9 10 while(!stopped){ if(paused){ this.yield(); // Cela donne la main aux autres threads. } else{ // Les traitements lorsque le thread n'est pas en pause. } }
Le yield() ne sert à rien... Il donne la main aux autres threads, mais qu'est-ce que ça change?
"Tout programme qui fonctionne avec un yield() doit fonctionner tout aussi bien sans le yield()" (dixit mon prof de systèmes concurrents) :)

Salut,
Voici l'exemple que donne Sun pour remplacer l'usage des fonctions "resume" et "suspend" :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
public void run() {
        while (true) {
            try {
                Thread.currentThread().sleep(interval);
 
                synchronized(this) {
                    while (threadSuspended)
                        wait();
                }
            } catch (InterruptedException e){}            
        }
    }
}

23/10/2006, 14h27
Kikito

Citation:

Envoyé par ®om

Le yield() ne sert à rien... Il donne la main aux autres threads, mais qu'est-ce que ça change?
"Tout programme qui fonctionne avec un yield() doit fonctionner tout aussi bien sans le yield()" (dixit mon prof de systèmes concurrents) :)

Oui le programme fonctionnera également sans le yield, mais il permet quand même de redonner la main plus rapidement aux autres threads, sans le yield il y a de fortes chances que le thread continue de boucler dans le while un bon nombre de fois avant de donner la main aux autres threads.
La le "if(paused){" est tout en haut du run ce n'est pas trop grave car une boucle va très vite mais si tu as une opération entre le while et le if, ne pas mettre de yield peut augmenter significativement le temps d'éxécution.
23/10/2006, 15h51
®om

Citation:

Envoyé par Kikito

Oui le programme fonctionnera également sans le yield, mais il permet quand même de redonner la main plus rapidement aux autres threads, sans le yield il y a de fortes chances que le thread continue de boucler dans le while un bon nombre de fois avant de donner la main aux autres threads.
La le "if(paused){" est tout en haut du run ce n'est pas trop grave car une boucle va très vite mais si tu as une opération entre le while et le if, ne pas mettre de yield peut augmenter significativement le temps d'éxécution.

Donc le programme ne fonctionne pas correctement sans le yield() (boucle infinie à ne rien faire)... Il est incorrect...
C'est pour ça qu'il ne faut pas utiliser de l'attente active mais de l'attente passive... Par exemple par un moniteur ou un sémaphore...
23/10/2006, 16h14
Kikito

Heu je n'ai pas de programme mais si le programme fonctionnerait correctement, et la boucle n'est pas infinie, mais sans le yield c'est le programme qui décide tout seul du moment où aller regarder les autres threads, ce qui peut causer une augmentation du temps d'éxécution.

Et utiliser une sémaphore n'a pas le même but (pas sûr de ce que tu appelles un moniteur en francais), une sémaphore est à utiliser quand on ne veut pas dépasser un certain nombre de thread en simultané (l'utilisation d'un ThreadPoolExecutor est d'ailleurs plus simple), là l'intérêt du yield est de rendre la main aux autres threads tout de suite sans attendre que cela se fasse tout seul qq temps plus tard.

Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ExecutorService exec = Executors.newFixedThreadPool(2); exec.execute(new Thread(){ public void run(){ while(!stopped){ System.out.println("passe dans le while du thread 1"); if(paused){ //yield(); } } } }); exec.execute(new Thread(){ public void run(){ stopped = true; } }); exec.shutdown();
Sans le yield il fait 7 ou 8 prints avant de passer au second, avec le yield s'est instantané, le programme fdonnera bien le même résultat mais le yield permet quand même de gagner du temps.

23/10/2006, 19h23
®om

Citation:

Envoyé par Kikito

Heu je n'ai pas de programme mais si le programme fonctionnerait correctement, et la boucle n'est pas infinie, mais sans le yield c'est le programme qui décide tout seul du moment où aller regarder les autres threads, ce qui peut causer une augmentation du temps d'éxécution.

Plus précisément, c'est l'ordonnanceur, qui choisit l'ordre d'exécution des threads...

Citation:

Envoyé par Kikito

Et utiliser une sémaphore n'a pas le même but (pas sûr de ce que tu appelles un moniteur en francais), une sémaphore est à utiliser quand on ne veut pas dépasser un certain nombre de thread en simultané (l'utilisation d'un ThreadPoolExecutor est d'ailleurs plus simple)

C'est une application particulière du sémaphore... Tu peux très bien faire un sémaphore à 1 jeton pour simuler un verrou (et donc simuler une attente passive, ton "pause" prendrait le jeton et empêcherait la suite du code de s'exécuter jusqu'au "dépause")...

Citation:

Envoyé par Kikito

là l'intérêt du yield est de rendre la main aux autres threads tout de suite sans attendre que cela se fasse tout seul qq temps plus tard.

Et l'intérêt de changer de thread courant immédiatement est?

De plus, le yield() ne garantit pas que ça va changer de thread courant...

Citation:
Envoyé par Kikito
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ExecutorService exec = Executors.newFixedThreadPool(2); exec.execute(new Thread(){ public void run(){ while(!stopped){ System.out.println("passe dans le while du thread 1"); if(paused){ //yield(); } } } }); exec.execute(new Thread(){ public void run(){ stopped = true; } }); exec.shutdown();
Sans le yield il fait 7 ou 8 prints avant de passer au second, avec le yield s'est instantané, le programme fdonnera bien le même résultat mais le yield permet quand même de gagner du temps.
Bah oui, tu m'étonnes...
On est dans le cas où le yield() change l'exécution du programme, et donc dans le cas où l'algorithme est mal conçu...

En utilisant une attente passive, tu gagnerais encore du temps par rapport à ce que tu fais là, car là dans l'état !stopped && paused, à chaque fois que le thread a la main, il refait le test "if paused... while !stopped" (un certain nombre de fois).
C'est clairement là que l'on doit utiliser une autre méthode qu'une attente active (surtout que ça doit bien bouffer du processeur)...

PS: regarde sur mon tuto dans la section "synchronisation coopérative":
http://rom.developpez.com/java-synchronisation/

Je veux bien que tu me montres comment ne pas utiliser d'attente active dans ce cas car je ne vois pas.

D'ailleurs je suis quasi sûr que ce que tu crois être de l'attente passive est de l'attente active, la méthode wait() étant native on ne sait pas exactement ce qu'elle fait, mais pour la méthode await() de java.util.concurrent.locks.Condition ce n'est qu'une attente active masquée :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 public final void await() throws InterruptedException { if (Thread.interrupted()) throw new InterruptedException(); Node node = addConditionWaiter(); int savedState = fullyRelease(node); int interruptMode = 0; while (!isOnSyncQueue(node)) { LockSupport.park(); if ((interruptMode = checkInterruptWhileWaiting(node)) != 0) break; } if (acquireQueued(node, savedState) && interruptMode != THROW_IE) interruptMode = REINTERRUPT; if (interruptMode != 0) reportInterruptAfterWait(interruptMode); }
Et même si wait() était elle passive (j'en doute), on ne peut l'uitliser sans attente active que dans le même thread ( sinon déclenchement de l'exception thread not owner ).
Cela mle semble donc impossible, ceci dit s'il existe un moyen ça m'intéresse vraiment de le connaitre.

Edit: je ne parle biensûr pas des sleep() qui sont passifs mais qui ne résoudrait pas le problème ( il y aurait juste moins de passage dans la boucle avec un sleep(5) ou sleep(10) ).

Citation:

Envoyé par Kikito

Je veux bien que tu me montres comment ne pas utiliser d'attente active dans ce cas car je ne vois pas.

D'ailleurs je suis quasi sûr que ce que tu crois être de l'attente passive est de l'attente active, la méthode wait() étant native on ne sait pas exactement ce qu'elle fait, mais pour la méthode await() de java.util.concurrent.locks.Condition ce n'est qu'une attente active masquée :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public final void await() throws InterruptedException {
            if (Thread.interrupted()) 
                throw new InterruptedException();
            Node node = addConditionWaiter();
            int savedState = fullyRelease(node);
            int interruptMode = 0;
            while (!isOnSyncQueue(node)) {
                LockSupport.park();
                if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
                    break;
            }
            if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
                interruptMode = REINTERRUPT;
            if (interruptMode != 0)
                reportInterruptAfterWait(interruptMode);
        }

Et même si wait() était elle passive (j'en doute), on ne peut l'uitliser sans attente active que dans le même thread ( sinon déclenchement de l'exception thread not owner ).
Cela mle semble donc impossible, ceci dit s'il existe un moyen ça m'intéresse vraiment de le connaitre.

Edit: je ne parle biensûr pas des sleep() qui sont passifs mais qui ne résoudrait pas le problème ( il y aurait juste moins de passage dans la boucle avec un sleep(5) ou sleep(10) ).

Je ne sais pas où tu as eu ce code, Condition est une interface (tu as dû l'avoir dans une classe l'implémentant)...

Cependant, je ne suis pas d'accord avec toi, ça n'est pas de l'attente active (ça n'est pas parce qu'il y a un while que c'est de l'attente active, toujours voir III.A.1 dans le tuto), Une des méthodes dans ce while est forcément passive...

Quand tu dis "on ne peut l'utiliser sans attente active que dans le même thread", c'est faux, wait() s'applique sur n'importe quel objet, pas forcément le Thread en question...

Voici un bout de code que je viens de faire pour montrer comment faire une attente passive pour pauser un thread, en utilisant le moniteur de la classe Object (wait() et notify()):

Code:

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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
public class AttentePassive {
 
    private final Object lock = new Object();
 
    private Thread thread;
 
    private boolean stopped;
    private boolean paused;
    private int i;
 
    public AttentePassive() {
        new Thread() {
 
            @Override public void run() {
                methodThreadSepare();
            }
        }.start();
    }
 
    public void methodThreadSepare() {
        while(!stopped) {
            synchronized(lock) {
                while(paused) {
                    try {
                        lock.wait();
                    } catch(InterruptedException e) {}
                }
            }
            System.out.println(i++);
        }
    }
 
    public void pauseThread() {
        synchronized(lock) {
            paused = true;
        }
    }
 
    public void unpauseThread() {
        synchronized(lock) {
            paused = false;
            lock.notify();
        }
    }
 
    public void stop() {
        synchronized(lock) {
            unpauseThread();
            stopped = true;
        }
    }
 
    public static void main(String... args) {
        final AttentePassive attentePassive = new AttentePassive();
        /* On lance un robot qui à intervalles prédéfinis pause et unpause le thread (pour le test). */
        new Thread() {
            @Override public void run() {
                try {
                    Thread.sleep(500);
                } catch(InterruptedException e) {}
                attentePassive.pauseThread();
                try {
                    Thread.sleep(1500);
                } catch(InterruptedException e) {}
                attentePassive.unpauseThread();
                try {
                    Thread.sleep(500);
                } catch(InterruptedException e) {}
                attentePassive.pauseThread();
                try {
                    Thread.sleep(1500);
                } catch(InterruptedException e) {}
                attentePassive.unpauseThread();
                try {
                    Thread.sleep(500);
                } catch(InterruptedException e) {}
                attentePassive.stop();
            }
        }.start();
    }
 
}

Il n'est pas commenté, si tu as des questions, n'hésite pas :)

Et avec le package java.util.concurrent au lieu du moniteur de Object (car le moniteur de Object est équivalent à un Lock limité à une seule variable condition, ici ça suffit, mais dans le cas général, ça ne suffit pas):

Code:

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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
 
public class AttentePassiveConcurrent {
 
    private final Lock lock = new ReentrantLock();
    private final Condition notPaused = lock.newCondition();
 
    private Thread thread;
 
    private boolean stopped;
    private boolean paused;
    private int i;
 
    public AttentePassiveConcurrent() {
        new Thread() {
 
            @Override public void run() {
                methodThreadSepare();
            }
        }.start();
    }
 
    public void methodThreadSepare() {
        while(!stopped) {
            lock.lock();
            while(paused) {
                try {
                    notPaused.await();
                } catch(InterruptedException e) {}
            }
            lock.unlock();
            System.out.println(i++);
        }
    }
 
    public void pauseThread() {
        lock.lock();
        paused = true;
        lock.unlock();
    }
 
    public void unpauseThread() {
        lock.lock();
        paused = false;
        notPaused.signal();
        lock.unlock();
    }
 
    public void stop() {
        lock.lock();
        unpauseThread();
        stopped = true;
        lock.unlock();
    }
 
    public static void main(String... args) {
        final AttentePassive attentePassive = new AttentePassive();
        /* On lance un robot qui à intervalles prédéfinis pause et unpause le thread (pour le test). */
        new Thread() {
 
            @Override public void run() {
                try {
                    Thread.sleep(500);
                } catch(InterruptedException e) {}
                attentePassive.pauseThread();
                try {
                    Thread.sleep(1500);
                } catch(InterruptedException e) {}
                attentePassive.unpauseThread();
                try {
                    Thread.sleep(500);
                } catch(InterruptedException e) {}
                attentePassive.pauseThread();
                try {
                    Thread.sleep(1500);
                } catch(InterruptedException e) {}
                attentePassive.unpauseThread();
                try {
                    Thread.sleep(500);
                } catch(InterruptedException e) {}
                attentePassive.stop();
            }
        }.start();
    }
 
}

24/10/2006, 18h19
Kikito
Merci d'avoir pris le temps de répondre.

Ok avec toi concernant le wait() j'ai parlé trop vite il suffit en effet d'utiliser un objet.

Là ou je suis moins d'accord c'est concernant le while et la définition du actif, le bout de code tiré de AbstractQueuedSynchronizer.java à priori ( lu rapidement ) empeche le thread courant d'être programmer dans le temps (schedule) puis vérifie que le thread n'a pas été intérrompu en boucle, je ne considère pas ça comme une attente utile au déroulement de l'application.
Je ne vois pas de grosses différences avec un :
Code:

1 2 3 4 5 try { LockSupport.park(); Thread.sleep(5); //ou même yield() qui est utile ! } catch(InterruptedException e) {}
Donc oui c'est clair faire un await() sur une Condition c'est beaucoup plus classe et stylé et la partie non sympatique est immergé mais est-ce que ça change vraiment qq chose en terme de fonctionnement global ou de performances ? je suis moins sûr.

Edit: et j'aimerais vérifier mais ça ne m'étonnerait vraiment pas que wait() soit juste une boucle qui attend un notify() à intervalle régulier ;)

A priori après qq recherches ça semble être dans interrupt_md.c :
Code:

1 2 3 while ((sig = lookupSignal()) == -1) { sigMonitorWait(); }
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 static void sigMonitorWait() { thread_t self = thr_self(); unsigned int saved_count = userSigMon.count; sysAssert(userSigMon.owner == self); sysAssert(userSigMon.count > 0); userSigMon.count = 0; userSigMon.owner = 0; condvarWait(&userSigMon.condvar, &userSigMon.mutex, CONDVAR_WAIT); sysAssert(userSigMon.owner == 0); sysAssert(userSigMon.count == 0); userSigMon.count = saved_count; userSigMon.owner = self; }
Je n'irais pas éplucher le code c de java pour savoir exactement ce que ça fait mais ça ne semble pas très passif ça fait les mêmes actions en boucle ;)

24/10/2006, 20h29
®om

Ca utilise simplement les primitives d'attente passive du système d'exploitation (heureusement qu'il y en a et qu'on n'est pas obligé d'utiliser de l'attente active, tu imagines?)...
condvarWait doit être passive (vu le nom) :)

Citation:

Envoyé par Kikito

Là ou je suis moins d'accord c'est concernant le while et la définition du actif, le bout de code tiré de AbstractQueuedSynchronizer.java à priori ( lu rapidement ) empeche le thread courant d'être programmer dans le temps (schedule) puis vérifie que le thread n'a pas été intérrompu en boucle

Dans mon tuto, regarde ce bout de code:
Code:

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 class ListeTab { private String[] tab = new String[50]; private int index = 0; synchronized void ajoute(String s) { tab[index] = s; index++; notify(); System.out.println("notify() exécuté"); } synchronized String getPremierElementBloquant() { //tant que la liste est vide while(index == 0) { try { //attente passive wait(); } catch(InterruptedException ie) { ie.printStackTrace(); } } return tab[0]; } }
Tu ne penses pas que c'est le même type de while (qui ne tourne pas "en boucle", mais qui permet simplement de revérifier la condition une fois que l'attente passive est terminée)?