Threads, wait() und notify()

[mad-din]

Hi Leute!

Ich hab zwei Klassen, die von Thread erben und Runnable implementieren. Dann gibt es noch eine ConcurrentLinkedQueue als Singleton, Thread A schreibt ständig Daten in die Queue rein. Thread B liest diese auch ständig wieder aus (dazu habend die run()-Methoden jeweils eine Endlosschleife). So, jetzt will ich aber, dass Thread B solange nichts tut, bis eine gewisse Anzahl von Elementen in der Queue ist. Sind dann sagen wir mal 500 Elemente mindestens drin, soll Thread A solange warten, bis Thread B alle abgearbeitet hat. Es sollte nicht so sein, dass Thread B jetzt 300 Elemente abarbeitet und dann Thread A wieder 10 Elemente reinschreibt und dann Thread B wieder weitermacht. Wenn Thread B einmal anfängt, soll er solange arbeiten bis er fertig ist und dann wieder automatisch warten. Geht das überhaupt, was ich vorhab?

Viele Grüße,
Martin

 

[mad-din]

Hat sich erledigt!

Viele Grüße,
Martin

 

[tfa]

Klar geht das. Sieht dir Locks und Conditions an. In der API-Doku gibt es hierzu sogar Bespielcode, das du deinen Anforderungen anpassen kannst.

 

[FArt]

Klar, mit notify() und wait() bist du schon richtig. Du musst halt deine Bedingng, wann gewartet wird und wann benachrichtigt wird, berücksichtigen.

Ist übrigens ein Standardproblem: suche mal nach Producer / Consumer

Wirf mal einen Blick in das Package java.util.concurrent, vermutlich musst du gar nicht selber mit Threads rumwerkeln...

 

[tfa]

Er benutzt ja schon eine Queue aus dem Concurrent-Package, und das würde ich nicht mit dem alten wait/notify mischen.

 

[FArt]

Er benutzt ja schon eine Queue aus dem Concurrent-Package, und das würde ich nicht mit dem alten wait/notify mischen.

Auf keinen Fall mischen. Im Gegenteil, notify() und wait() wird man mit dem concurrent-Package seltener selber benötigen. Ich hätte aber intuitiv auf eine BlockingQueue gesetzt ;-)

 

[mad-din]

Hi!


Also das man es nicht mischen sollte, ist mir jetzt auch aufgefallen Das eigentliche Problem ist, dass mir die CPU-Auslastung durch die zwei Threads mal eben auf 100% gestiegen ist. Ist aber auch irgendwie klar, da laufen zwei Threads mit Endlosschleifen und die laufen immer, obwohl das gar nicht nötig ist. Deswegen dachte ich, wenn ich den einen mal eben warten lasse, dann geht die Rechenleistung wieder runter (ich hab auch irgendwo mal gelesen, dass man dadurch nur noch 1/3 der Rechenleistung gegenüber vorher benötigt).

Jetzt schau ich mir mal das mit Lock an, da ich meine ConcurrentLinkedQueue gern behalten würde.

Danke einstweilen

Viele Grüße,
Martin

 

[FArt]

Problem: Endlosschleife und ständiges pollen
Lösung: notify() und wait() oder eine blockierende Queue (s.o.)?

 

[mad-din]

Hi!

Ja, Endlosschleife und das ständige Pollen ist das Problem. Ich hab mir auch die Sache mit den Locks angesehen, werd mir jetzt aber auch mal die BlockedQueue ansehen, mal schaun, was mir mehr gefällt

Viele Grüße,
Martin

 

[Gast]

Noch mal der Hinweis: Google - Producer/Consumer

... das Rad existiert, und es ist schon rund!

 

[mad-din]

Hi!

Das Prinzip ist mir bewusst, ich suche nur nach einer geeigneten Lösung, die mir den Prozesser nicht auf Anschlag laufen lässt. Aber da werde ich so wie es aussieht keinen Erfolg haben, da eine normale Endlosschleife die CPU schon auf knapp 70% jagt, was bei zwei Endlosschleifen dann passiert, kann man sich denken.


Viele Grüße,
Martin


P.S.: komischerweise, wenn ich aber einen Sleep nach jedem Einfügen einbaue, ist die CPU-Auslastung nichtmal bei 15% Kann sich das jemand erklären?