Discussion :

[masto]

Salut à tous, j'ai une ptite question :

J'ai deux méthodes

A()

B()

J'aimerai faire en sorte que deux treads ne puissent appeler les deux méthodes en même temps mais que deux threads puissent appeller les méthode A() ou (exclusif) b() en même temps.

EX :

Thread 1 : appelle A()
Thread 2 : appelle A()

OK


Thread 1 : appelle B()
Thread 2 : appelle B()
Thread 3 : appelle B()

OK


Thread 1 : appelle B()
Thread 2 : appelle A()

PAS OK

Vous voyez le truc...

Merci

[nuke_y]

Donc en bref, B ne doit pas pouvoir être appelée tant que A est en cours d'exécution et pareil pour A.

Et si tu gères des variables globales aInRun et bInRun ce qui donne :

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
 
public class MaClasse ... Thread...
{
 boolean aInRun = false;
 boolean bInRun = false;
 
 public void a()
{
 aInRun = true;
 ...
 
 aInRun=false;
}
 
 public void b()
{
 bInRun = true;
 ...
 
 bInRun=false;
}
 
public MaClasse()
{
  .... 
  if (!aInRun) b(); // impossible de lancer b en même temps que a
  ...
  if (!nInRun) a(); // impossible de lancer a en même temps que b
  ...
  while(aInRun); // on attend la fin de a pour pouvoir lancer b
  b();
}

Et si tes threads ne partagent pas les infos (je suis pas très à l'aise avec les thread) met les2 variables globales en static.

[plopinou]

Mouay, il manque des synchronized déjà pour l'accès aux ressources communes. Ensuite, le while(aInRun);, il y a rien de pire pour gérer des threads, sauf si on veut pourrir les perfs du proc, c'est donc à bannir !! Il faut utiliser les méthodes wait() et notify() pour endormir et réveiller un Thread.

Bon, pour revenir au problème, je dirai que l'idée des variables aInRun et bInRun est pas mal (à utiliser avec des getters "synchronized"), mais qu'il faudrait en plus réserver la ressource si possible, genre

Code :

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

1
2
3
4
5
6
7
8
public synchronized tryToAllocateA() {
  if (!bInRun) {
    aInRun = true;
    return true;
  } else {
    return false;
  }
}

Parceque si on sépare la réservation du test, on perd tout l'intéret du synchronized.

Ensuite, quand on veut appeller A ou B, si la réservation n'est pas possible, on endors le processus. Ca donne donc quelquechose du genre :

Code :

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

1
2
3
4
5
6
7
8
public void A() {
  while ( tryToAllocateA() ) {
    wait();
  }
  ...
  freeA();
  notifyAll();
}

Bon, je ne suis pas non plus un spécialiste des threads, mais ça devrait plutôt ressembler à ça je pense. Après, on peux améliorer, notament en gérant une liste fifo des threads selon leut demande de réservation, pour que ce soit plus équitable, et on remplacer les notifyAll() par un notify() sur le bon Thread.

[nuke_y]

Bah j'avais prévenu que j'étais pas à l'aise avec les threads...

[masto]

Merci pour les réponses.


Il s'agit là d'une bonne piste mais je me pose une question concernant la méthode freeA().

Si j'ai 2 thread exécutant en ce moment même la méthode A, sachant qu'aucun thread n'exécute la méthode B.

Le thread 1 va passer en premier dans freeA() et va mettre AInRun à false.
(Le thread 2 est encore quelque part dans la méthode A...)

Arrive alors un thread qui exécute la méthode B. Le flag AInRun étant à faux, il passe et exécute la méthode B.

On se retrouve donc avec un tread exécutant A et un thread exécutant B...

En fait, c'est la méthode free qui ferait foirer dans ce cas précis. Je me dis alors que les deux booleéns ne sont ptet pas suffisants..

Qu'en pensez-vous ?

[nuke_y]

Mhmm chaque Thread devrait posséder ses propres booléen alors ...

[plopinou]

Tu as parfaitement raison. Tu peux dans ce cas utiliser un entier au lieu d'un booléen, pour compter le nombre de Thread qui exécute A (ou B).

[nuke_y]

Pas bête les entiers, incrémentation pour 1 thread de plus à True et décrementation pr 1 de moins. Avec test aInRun > 0.

Sinon il faudrait ptet voir avec un espèce de pool de thread qui s'occupe de gérer en amont ce genre de chose. Il s'occupe de savoir si un de ses thread est dans une des 2 méthodes et renvoit le résultat.

[plopinou]

Mhmm chaque Thread devrait posséder ses propres booléen alors ...

Non, je dirai plutôt que les ressources partagées doivent être centralisées dans une autre classe, sinon il faudrait demander à chaque thread ce qu'il exécute, et ça me semble assez difficile à gérer. Ca doit être un truc du genre

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
public class Ressource {
 
  private int nbThreadRunningA;
  private int nbThreadRunningB;
  private static Ressource instance = null;
 
  protected Ressource() {
    nbThreadRunningA = 0;
    nbThreadRunningB = 0;
  }
 
  public static Ressource getInstance() {
    if (instance  == null) {
      instance = new Ressource();
    }
    return instance;
  }
 
  public synchronized void tryToAllocateA() { 
    if (nbThreadRunningB  == 0) { 
      nbThreadRunningA++;
      return true; 
    } else { 
      return false; 
    } 
  }
 
  public synchronized void freeA() {
    nbThreadRunningA--;
  }
 
   ...
 
}

Ensuite, pour les autres threads, le principe reste le même.