Le sommeil d'un thread jusqu'à ce qu'un événement est assisté, dans un autre thread à partir d'une autre classe

Utiliser un CountDownLatch avec une valeur initiale de 1.

Faire de la 3e classe appel compte à rebours() une fois le traitement terminé. Le thread appelant peut ensuite appeler await(), qui permet de bloquer jusqu'à ce que le traitement est terminé.

Vous souhaitez utiliser un comptage sémaphore. Les variables de Condition sont destinés pour l'ordonnancement des threads à l'intérieur d'un moniteur. Ce n'est pas ce que vous essayez de faire.

Vous créez un comptage sémaphore et réglez le décompte à zéro

//create a counting semaphore with an initial count of zero
java.util.concurrent.Semaphore s = new java.util.concurrent.Semaphore(0);

Vous passer le sémaphore à votre classe le fait le traitement. Quand c'est fini, il augmente le nombre à 1 en appelant s.release().

Pour bloquer un thread jusqu'à ce que le processeur est fini, vous appelez s.aquire(). Cet appel sera la cause de votre autre thread pour bloquer jusqu'à ce que le processeur appels s.release().

C'est la solution la plus simple.

Btw, s.aquire() et s.release() sont thread-safe, vous n'avez pas besoin d'utiliser le synchroniser mot-clé. Les Threads peuvent partager des références à un feu et appeler ses méthodes sans verrouillage.

Mise à JOUR:

Je vais répondre à votre commentaire ici au lieu de faire un nouveau commentaire.

Oui, dans votre cas, un wait()/notify() la solution est similaire à l'utilisation d'un sémaphore. À la réécriture du programme de solution avec un sémaphore, il ressemblerait à:

java.util.concurrent.Semaphore s = new java.util.concurrent.Semaphore(0);

public setDone() {
    s.release();
}

public waitUntilDone() {
     s.aquire();
}

Il est beaucoup plus simple et vous n'avez pas besoin d'une inutile de verrouillage (avis j'ai enlevé le mot-clé synchronized à partir de la méthode de cad.).

Il y a 2 différences entre les variables de condition (wait()/notify()) et les sémaphores.

Différence #1: les appels de notify() peuvent être perdus, les appels à la release() ne sont jamais perdus

La première différence est que les appels à notify() sont perdues si il n'y a pas de fil d'attente via un appel à wait(). Le travail consiste à vérifier l'état avant l'appel à wait(). Fondamentalement, nous devons nous rappeler que notify() a été appelé avec une variable partagée, afin de ne pas accidentellement l'appel en attente() après que le travailleur appels notify(), ou bien nous l'impasse. Le comptage des sémaphores du travail, peu importe l'ordre dans lequel les acquérir() et release() sont appelées parce qu'elles maintiennent un nombre à l'intérieur.

Différence #2: les appels à wait() effectue automatiquement la libération d'un verrou, les appels à acquérir() ne sont pas

Des renseignements contextuels de l'aide ici. Dans votre programme de la boolean done = false;
la variable est la condition, mais il n'est pas de la variable de condition. Confusion terminologique, je sais. La variable de condition est la variable qui a des opérations de wait() et notify(). Chaque objet en Java a une variable de condition cachées à l'intérieur et une serrure correspondante.

Toutes les variables de condition sont associés avec un cadenas. Vous devez acquérir le verrou avant de vous pouvez appeler wait() et notify() (vous obtiendrez une exception d'exécution si vous n'en avez pas, essayez). Une fois que le verrou est acquis, les appels à wait() automatiquement libérer le verrou, permettant à un autre fil à l'intérieur du moniteur pour peut-être appeler notify(). Parfois, c'est exactement ce que vous voulez, et en essayant de simuler ce comportement avec les sémaphores sera beaucoup plus compliqué.

Note: je suis en utilisant la définition académique de moniteur qui diffère totalement de la Java définition d'un moniteur.