synchronized und notify / notifyAll

[kaesebrot]

Hi,

hab auf die schnelle keine Antwort auf folgende Frage finden können:

* Thread1 und Thread2 haben jeweils einen synchronized Block mit Object X.
* Thread2 betritt regelmäßig den Block und führt eine aufwändigere Operation durch

Wie kann ich sicherstellen, daß Thread1 garantiert drankommt, wenn Thread2 den Block verläßt? Ich bin mir nicht sicher, ob ich das gewünschte Verhalten mit X.notifyAll() erzielen kann. In der Doku steht, daß nur Threads die mittels wait() auf X warten "aufgeweckt" werden. Also ist der Ansatz warscheinlich falsch.

Rahmenbedingungen:
* Thread1 soll auch ohne Zutun von Thread2 arbeiten können
* Thread2 kennt Thread1 nicht



viele Grüße,
Käse

 

[diggaa1984]

soll es denn IMMER alternierend geschehen? also immer T1 -> T2 -> T1 -> T2 etc

 

[kaesebrot]

soll es denn IMMER alternierend geschehen? also immer T1 -> T2 -> T1 -> T2 etc

Nein soll es nicht. Ich konkretisiere das Problem am besten mal ein wenig:

Es geht um einen Server der viele Clients bedienen soll. Der Server führt eine Liste der angemeldeten Clients. Thread1 ist dafür zuständig die An- und Abmeldung der Clients zu registrieren und die Liste entsprechend aktuell zu halten. Die Liste wird hier also nur kurz benötigt.
Thread2 wird beim versenden einer Broadcast-Nachricht zuständig. Thread2 geht hierzu die Liste der angemeldeten Clients durch und schreibt die Daten jeweils in einen sende-Buffer. Das dauert im Vergleich zu Thread1 ziemlich lang.

Problematik: Werden viele Daten versendet, hat Thread2 viel zu tun. Ich habe die Befürchtung das in einem solchen Fall Thread1 verhungern kann (siehe: http://java.sun.com/docs/books/tutorial/essential/concurrency/starvelive.html).

Diesem Verhungern möchte ich vorbeugen, indem ich den Threads, die gerade wg. synchronized(ListeDerAngemeldetenClients) blockiert sind das Zepter übergebe bevor ich wieder anfange was zu versenden.


Eine Lösung wäre, daß sich Thread1 irgendwo einträgt bevor es wartet und von Thread2 aktiviert wird. Gibt es eine schönere Lösung bzw. ist dies überhaupt eine sinnvolle Lösung?



viele Grüße,
Käse

 

[André Uhres]

Wie kann ich sicherstellen, daß Thread1 garantiert drankommt, wenn Thread2 den Block verläßt?

Version 1.5 von Java und sein Paket java.util.concurrent (sowie seine Unterpakete) liefern
Synchronisationswerkzeuge von höherem Niveau.

Ein sehr nützliches Werkzeug ist Executor. Es handelt sich um eine blockierende Warteliste
von durchzuführenden Aktionen. Man findet genau denselben Mechanismus wieder,
wenn man den Thread benutzt, welcher der graphischen Anzeige von Swing gewidmet ist (Event Dispatch Thread):
SwingUtilities.invokeLater(Runnable) stellt eine Aktion in die Warteschlange, die in dem Thread durchzuführen ist,
welcher der graphischen Anzeige gewidmet ist.

Hier ist ein Beispiel der Benutzung von Executor:

Executor executor = Executors.newSingleThreadExecutor () ;
executor.execute ( new  Runnable () {
     public  void  run () {
         System.out.println ( "asynchroner Aufruf 1" ) ;
     }
}) ;
executor.execute ( new  Runnable () {
     public  void  run () {
         System.out.println ( "asynchroner Aufruf 2" ) ;
     }
}) ;

Dieses Beispiel führt Runnables asynchron gegenüber dem laufenden Thread aus, aber gewährleistet,
dass sie in der Aufrufreihenfolge nacheinander durchgeführt werden.

 

[kaesebrot]

Danke für die Info, ich werde mal das Packet mal genauer anschauen.



viele Grüße,
Käse

 

[Gelöschtes Mitglied 5909]

ich bin jetzt nicht grad der multi threading experte, aber du könntest mit einer höheren priorität (MAX_PRIOTIRY) versuchen zu verhindern dass der thread verhungert, das ganze ist ja eigentlich für genau diesen fall gemacht wenn ich mich nicht täusch

 

[kaesebrot]

Hi,

das Problem könnte eventuell damit in den Griff bekommen werden, jedoch möchte ich, daß alle Threads mit gleicher Priorität behandelt werden.


viele Grüße,
Käse

 

[didjitalist]

Dein Thread1 übernimmt eine Aufräumarbeit, die Thread2 unmittelbar entlasten kann. Daher erscheint es mir sinnvoller, das durch einen einzigen Thread zu lösen. Oder anders gesagt, die Aktion, die entscheiden kann, welche Clients noch mit dem Server verbunden sind, sollte auch vollständige Kontrolle über die Aktion haben, die Daten versendet.

 

[André Uhres]

..durch einen einzigen Thread zu lösen..

..oder durch Threads, die mittels Executor in der Aufrufreihenfolge nacheinander durchgeführt werden.