{"id":6881,"date":"2015-12-28T09:59:45","date_gmt":"2015-12-28T08:59:45","guid":{"rendered":"https:\/\/www.herr-rau.de\/wordpress\/?p=6881"},"modified":"2025-03-15T11:24:36","modified_gmt":"2025-03-15T10:24:36","slug":"threads-iii-erzeuger-verbraucher-und-ein-neuer-zustand","status":"publish","type":"post","link":"https:\/\/www.herr-rau.de\/wordpress\/2015\/12\/threads-iii-erzeuger-verbraucher-und-ein-neuer-zustand.htm","title":{"rendered":"Threads III – Erzeuger, Verbraucher und ein neuer Zustand"},"content":{"rendered":"
(1 Kommentare.<\/a>)<\/small> <\/div>\n

(Fortsetzung von hier.<\/a>) Im bisherigen Beispiel ging es um Toilettenbenutzer, die auf eine leere Toilette warten, sie dann auf jeden Fall benutzen k\u00f6nnen und auf jeden Fall wieder herausgehen, so dass die Toilette dann f\u00fcr den n\u00e4chsten Besuch wieder frei ist. Wir hatten quasi Erzeuger, die den kritischen Bereich betreten, wo auf jeden Fall Platz zum, \u00e4h, Erzeugen ist, und dann gehen sie wieder. Das erzeugte Produkt bleibt nicht etwa in der Toilette, sondern verschwindet im Orkus.
Daf\u00fcr reichen unsere bisherigen synchronisierten Methoden.<\/p>\n\n\n\n

Erzeuger und Verbraucher<\/h3>\n\n\n\n

Wir erweiterten jetzt unsere Aufgabe zu etwas, das allgemein Erzeuger-Verbraucher-Problem hei\u00dft. Dazu stellen wir uns einen oder mehrere Erzeuger vor, die ein Produkt erstellen und das an einem Speicherort abstellen wollen, das aber nur k\u00f6nnen, wenn dort Platz ist.<\/em> Dazu kommen noch ein oder mehrere Verbraucher, die regelm\u00e4\u00dfig diesen gemeinsamen Speicherort aufsuchen, um von dort ein Produkt abzuholen – das geht nat\u00fcrlich nur, wenn dort auch ein Produkt f\u00fcr sie liegt.<\/em><\/p>\n\n\n\n

Damit kommt ein neuer Faktor hinzu. Nicht nur gibt es einen kritischen Bereich, der nur von einem (sagen wir mal) auf einmal betreten werden darf. Au\u00dferdem gibt es in diesem Bereich noch eine weitere Bedingung, die erf\u00fcllt sein muss: der Lieferant muss dort Platz f\u00fcr sein Produkt haben, und der Abholer muss dort eine Kiste zum Abholen vorfinden.<\/p>\n\n\n\n

\"threads_erz-verb\"<\/figure>\n\n\n\n

L\u00f6sung 1 (keine gute L\u00f6sung)<\/h3>\n\n\n\n

In einer Schleife produziert der Erzeuger immer wieder ein Produkt (im Beispiel eine Kiste) und ruft danach die synchronisierte Methode hineinlegen(Kiste)<\/code> des Speicher-Objekts (der ein Monitor ist) auf. Damit hat er ein Exklusivrecht auf die vom Monitor \u00fcberwachten Methoden. Wenn dort kein Platz zum Ablegen der Kiste ist, dann hilft einfaches Warten (in einer Schleife etwa) auch nicht: Der Verbraucher kann ja nicht hinein, um die Kiste dort herauszuholen, solange der Erzeuger die Monitormethode benutzt.<\/p>\n\n\n\n

Ebenso der Verbraucher: Wenn der die Methode herausholen()<\/code> aufruft, die als R\u00fcckgabetyp eine Kiste hat, was soll dann passieren, wenn gar keine Kiste im Speicher ist? Einfaches Warten auf eine Kiste funktioniert ebenso wenig wie oben.<\/p>\n\n\n\n

Eine L\u00f6sung ist: Nu, wenn keine Kiste da ist, dann gibt die Methode herausholen einfach null<\/code> zur\u00fcck statt einer Kiste. Das hei\u00dft aber, dass der Verbraucher komplizierter wird: Er kann nicht sichergehen, dass er nach dem Holen eine Kiste hat und muss, wenn er stattdessen null<\/code> hat, diesen einen Kistenholversuch solange wiederholen, bis er doch eine Kiste hat. Dann kann er regul\u00e4r weitermachen.
Ebenso der Erzeuger: Wenn der eine Kiste hineinlegen will, gibt es \u00fcblicherweise keinen R\u00fcckgabetyp (void<\/code>). Man m\u00fcsste stattdessen eine R\u00fcckgabe machen, boolean oder die Kiste selber, anhand derer der Erzeuger unterscheiden kann, ob der Hineinlegen-Versuch erfolgreich war oder nicht. Wenn nicht, wird der Versuch mit der urspr\u00fcnglichen Kiste solange wiederholt, bis der Erzeuger sie doch los wird. Dann kann er regul\u00e4r weitermachen.<\/p>\n\n\n\n

Diese L\u00f6sung funktioniert. Aber zum einen ist der Code dann etwas umst\u00e4ndlich, zum anderen f\u00fchrt das dazu, dass der Erzeuger m\u00f6glicherweise immer und immer wieder versucht eine Kiste abzuliefern, auch wenn der Verbraucher noch so langsam arbeitet. (Oder umgekehrt.) Jeder Thread l\u00e4uft st\u00e4ndig in einer Schleife, auch wenn gar nichts passiert. Das kostet Rechenzeit.<\/p>\n\n\n\n

Deshalb macht man das anders.<\/p>\n\n\n\n

L\u00f6sung 2: Ein neuer Zustand<\/h3>\n\n\n\n

Wenn ein Erzeuger-Thread die synchronisierte hineinlegen<\/code>-Methode aufruft, dort aber keinen Platz findet, dann wird er ruhen geschickt. Damit gibt er, wichtig, seinen exklusiven Anspruch auf den Monitor vorl\u00e4ufig auf.<\/p>\n\n\n\n

Wenn dann mal endlich ein Verbraucher die Kiste abholt und Platz im Speicher-Bereich schafft, muss der Speicher\/Monitor danach dem Betriebssystem sagen, dass dies alle von ihm ruhen geschickten Threads aufwecken soll. Auch der ruhende Erzeuger wird so geweckt und versucht dann a) wieder exklusiven Anspruch auf den Monitor zu kriegen (falls das nicht klappt, ist er BLOCKED, siehe vorherigen Eintrag) und im Erfolgsfall b) macht er an genau der Stelle weiter, an der er ruhen geschickt wurde.<\/p>\n\n\n\n

Dieser neue Zustand hei\u00dft WAITING:<\/p>\n\n\n\n


<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Erzeuger und Verbraucher sehen im einfachsten Fall so aus:<\/p>\n\n\n\n

public class Erzeuger extends Thread  {
  \/\/ Attribute
  Speicher speicher;
  int produktionsnummer = 0;

  \/\/Konstruktor
  public Erzeuger(Speicher speicher) {
    this.speicher = speicher;
  }

  \/\/Methoden
  public void run() {
    while (produktionsnummer<20) {
      Kiste k = new Kiste(produktionsnummer);
      produktionsnummer++;
      speicher.hineinlegen(k);
    }
  }
}<\/code><\/pre>\n\n\n\n
public class Verbraucher extends Thread{\n    \/\/ Attribute\n    Speicher speicher;\n\n    \/\/Konstruktor\n    public Verbraucher(Speicher speicher) {\n        this.speicher = speicher;\n    }\n\n    \/\/Methoden\n    public void run() {\n        while (true) {\n            Kiste k = speicher.herausholen();\n        }\n    }\n}<\/code><\/pre>\n\n\n\n
Klar wird man noch ein sleep()<\/code> einbauen, damit das nicht gar so schnell geht, und da und dort ein System.out.println()<\/code>, damit man auch etwas mitkriegt davon, ob gerade eine Kiste produziert oder dem Speicher entnommen wurde, aber das ist eigentlich nur Dekoration.<\/p>\n\n\n\n
Schwieriger finde ich die Programmierung des Monitors:<\/p>\n\n\n\n
public class Speicher {\n  \/\/ Attribute\n  boolean istLeer = true;\n  Kiste eingelagerteKiste = null;\n\n  \/\/Konstruktor\n  public Speicher() {\n  }\n\n  \/\/Methoden\n  synchronized void hineinlegen(Kiste neueKiste) {        \n    while (!istLeer) { \n      \/\/exklusiver Zugang gelungen, aber fruchtlos\n      try {\n        wait(); \/\/geh ruhen\n      }\n      catch (Exception e) { System.out.println(e); }\n    }\n    \/\/exklusiver Zugang gelungen, und sinnvoll\n    istLeer = false;\n    eingelagerteKiste = neueKiste;\n    notifyAll(); \/\/Wecken der ruhenden Threads\n  }\n\n  synchronized Kiste herausholen() {\n    while (istLeer) {\n      \/\/exklusiver Zugang gelungen, aber fruchtlos\n      try {\n        wait(); \/\/geh ruhen\n      }\n      catch (Exception e) { System.out.println(e); }\n    }\n    \/\/exklusiver Zugang gelungen und sinnvoll\n    istLeer = true;\n    notifyAll(); \/\/Wecken der ruhenden Threads\n    return eingelagerteKiste;\n  }\n}<\/code><\/pre>\n\n\n\n
Mit dem wait()<\/code> in Zeile 15 und 29 wird der Thread, der diesen Befehl ausl\u00f6st, in unseren neuen WAITING-Zustand versetzt. Das muss aus Java-Gr\u00fcnden in einem try-catch-Block geschehen. Das notifyAll()<\/code> in Zeile 22 und 35 sagt dem Betriebssystem, dass wartende Threads jetzt geweckt werden sollen, auf dass sie erneut ihr Gl\u00fcck versuchen.<\/p>\n\n\n\n
Erkl\u00e4ren muss man jetzt nur die Schleifen um das wait()<\/code> herum, siehe Zeilen 12 und 26. Warum reicht da nicht ein einfaches if<\/code>?<\/p>\n\n\n\n
F\u00fcr diesen Fall:
Ein Erzeuger will die exklusive hineinlegen<\/code>-Methode aufrufen. Der Monitor ist gerade frei, der Erzeuger also nicht BLOCKED<\/code>, und trifft auf die Schleife, deren Bedingung wahr ist (der Speicher ist voll), so dass der Erzeuger in Winterschlaf versetzt wird (WAITING<\/code>).
Ein Verbraucher holt dann die Kiste heraus und alle schlafenden Threads werden geweckt. Auch unser erster Thread wird geweckt (ist RUNNABLE<\/code>), doch ebenso ein zweiter Erzeuger. Der zweite kommt zuerst dran (ist RUNNING<\/code>), kriegt exklusiven Zugang zum Monitor, legt eine Kiste ein, und verl\u00e4sst den kritischen Bereich. Jetzt erst kommt unser erster Thread an den Zug (RUNNING<\/code>), er kriegt seinen exklusiven Zugang zum Monitor – dummerweise ist aber schon wieder kein Platz mehr f\u00fcr die Kiste! Also muss er wieder ruhen und auf das n\u00e4chste Wecken warten.<\/p>\n\n\n\n
Will hei\u00dfen: Zum Zeitpunkt des Weckens ist die f\u00fcr den Erzeuger kritische Bedingung (dass Platz in der Ablage ist) zwar erf\u00fcllt, aber schon kurz danach, wenn der Erzeuger zum Zug kommt, kann sie schon wieder nicht mehr erf\u00fcllt sein.<\/p>\n\n\n\n

Aufgaben:<\/strong><\/p>\n\n\n\n