Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- parallelism:producerconsumer:start [2025/03/04 09:00] – [Tidying up loose ends] Martin Pabst
+++ parallelism:producerconsumer:start [2025/03/04 09:03] (aktuell) – [Tidying up loose ends] Martin Pabst
@@ Zeile 246: / Zeile 246: @@
 <WRAP center round tip 80%>
 In den obigen Erklärungen wurden ein paar Sachverhalte vereinfacht, damit Sie das Prinzip des passiven Wartens gut verstehen können. Vielleicht sind Ihnen daher ein paar kleinere Ungereimtheiten aufgefallen. Es wird Zeit, sie jetzt im Detail zu klären!
-  * Solange es nur **genau einen Erzeuger und genau einen Verbraucher** gibt, könnte man statt der while-Loops in den Methoden ''legPizzaDrauf'' und ''holPizzaAb'' auch einfach nur if-statements verwenden. Sobald es **mehrere Erzeuger/Verbraucher** gibt, könnte es aber sein, dass ein **Erzeuger** durch das ''notify()'' eines anderen **Erzeugers** "aufgeweckt" wurde und noch gar kein Platz auf dem Tresen vorhanden ist, um zusätzliche Pizzen abzulegen. In diesem Fall ist dann die ''while-loop'' unverzichtbar, da der Erzeuger "aufgeweckt" wurde ohne dass ein freier Platz im Austauschbereich geschaffen worden war. \\ In der Praxis könnte man in so einem Fall aber - noch besser - zwei unterschiedliche Monitore für Verbraucher und Erzeuger verwenden.
+  * Solange es nur **genau einen Erzeuger und genau einen Verbraucher** gibt, könnte man statt der while-Loops in den Methoden ''legPizzaDrauf'' und ''holPizzaAb'' auch einfach nur if-statements verwenden. Sobald es **mehrere Erzeuger/Verbraucher** gibt, könnte es aber sein, dass ein **Erzeuger** durch das ''notify()'' eines anderen **Erzeugers** "aufgeweckt" wurde. In diesem Fall ist dann die ''while-loop'' unverzichtbar, da der Erzeuger "aufgeweckt" wurde ohne dass ein freier Platz im Austauschbereich geschaffen worden war. \\ In der Praxis könnte man in so einem Fall aber - noch besser - zwei unterschiedliche Monitore für Verbraucher und Erzeuger verwenden.
-  * In den obigen Erklärungen wurde vereinfachend so getan, also ob der Aufruf von ''notify()'' durch den Erzeuger direkt den Verbraucher "aufweckt" (und umgekehrt), so dass letzterer **sofort** mit der Abarbeitung der Anweisung fortfährt, die auf die ''wait()''-Anweisung folgt. Aber dann wären ja sowohl Erzeuger als auch Verbraucher **gleichzeitig in der synchronized-Methode**! Insbesondere könnten nach dem ''notify()'' ohne Weiteres noch weitere Anweisungen in der ''synchronized''-Methode stehen. \\ \\ In der Tat sind die Abläufe in der Realität etwas komplexer. Jeder Thread in Java hat einen Zustand (//thread state//), der die Werte //new//, //runnable//, //running//, //waiting// und //terminated// annehmen kann. Nur im Zustand //running// werden die Anweisungen des Threads ausgeführt.
+  * In den obigen Erklärungen wurde vereinfachend so getan, also ob der Aufruf von ''notify()'' durch den Erzeuger direkt den Verbraucher "aufweckt" (und umgekehrt), so dass letzterer **sofort** mit der Abarbeitung der Anweisung fortfährt, die auf die ''wait()''-Anweisung folgt. Aber dann wären ja sowohl Erzeuger als auch Verbraucher **gleichzeitig in der synchronized-Methode**! Das **darf nicht sein**, denn nach dem ''notify()'' könnten ja ohne Weiteres noch weitere Anweisungen in der ''synchronized''-Methode stehen.:-/ \\ \\ In der Tat sind die Abläufe in der Realität etwas komplexer. Jeder Thread in Java hat einen Zustand (//thread state//), der die Werte //new//, //runnable//, //running//, //waiting// und //terminated// annehmen kann. Nur im Zustand //running// werden die Anweisungen des Threads ausgeführt.
 {{ :parallelism:producerconsumer:java-threadstates.svg?600 |}}
   * Durch den Aufruf von //wait()// des Monitor-Objekts geht der Thread in den Zustand //waiting// über. Wird später irgendwann die Methode //notify()// des Monitor-Objekts aufgerufen, so geht einer der aktuell für diesen Monitor wartenden Threads in den Zustand //runnable// über, **nicht jedoch in den Zustand running**! Erst, wenn **alle kritischen Bereiche** des Monitors vom letzten Thread verlassen wurden, wird einer der Threads vom Zustand ''runnable'' in den Zustand ''running'' versetzt und setzt seine Ausführung fort.