Discussion :

[asphalte]

Bonjour,

Après avoir épluché plusieurs tutoriels sur la synchronisation en Java, je n'arrive toujours pas à comprendre le blocage d'un thread de mon programme.

Le thread en question est lancé par :

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
 
private synchronized void waitingActions() {
  try {
    wait();
  } catch (InterruptedException e) {
    logger.warn(e.toString());
  }
}
 
public void run() {
  while (true) {
    System.out.println("Waiting...");
    waitingActions();
    System.out.println("condition treatment");
}

Il reste donc bloquer en attente d'un notify().

La méthode suivante est ensuite appelée par un autre thread :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public void addChanges(...) {
  for (ChangeType t : ChangeType.values())
    if (!pChanges.get(t).isEmpty())
      logger.info("Receive...");
    Set<ActionAbstract> actions = new HashSet<ActionAbstract>();
    System.out.println("block");
    synchronized (actionLock) {
      actions.addAll(executingActions);
    }
    System.out.println("unblock");

Cette méthode reste bloquer en attente de l'obtention du verrou déclaré de la manière suivante :

Code :

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

1
2
 
private final Boolean actionLock = true;

Je n'arrive pas à comprendre pourquoi le verrou n'est pas disponible. J'ai mis des messages sur toutes les autres méthodes (et verrouillages) de la classe et elles ne sont à priori pas appelées. La trace d'exécution obtenue est :

Code :

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

1
2
3
 
Waiting...
block

J'ai essayé de reproduire le blocage sur un exemple jouet et je n'ai pas réussi. Je dois surement passer à côté de quelque chose

[asphalte]

Le problème semble venir de l'utilisation de nombreux threads. En réorganisant les méthodes dans mes threads, le blocage disparaît.

Quelques explications pour ceux qui veulent comprendre et/ou me donner des explications sur le phénomène :
Le scénario original :
Thread A : serveur TCP pouvant appeler le addChanges() lors de la
réception d'une requête.
Thread B : celui qui fait le wait() et possède la méthode addChanges().
Thread C : père de D.
Thread D : partage des objects avec son père (C) et envoie toutes les n
secondes une requête au serveur TCP (A) qui appelle alors la méthode
addChanges() de B.

Le scénario corrigé :
Thread A : serveur TCP.
Thread B : celui qui fait le wait() et possède la méthode addChanges().
Thread C : père de Thread D et possède la méthode d'envoi d'une requête
au serveur TCP (A).
Thread D : appelle toutes les n secondes la méthode d'envoi d'une requête
de son père (C).