Fliegt irgendwann mal in den Try-Blocks ne Exception?

Lg Mokki

Ok, dann bin ich raus •﹏•

Lg Mokki

Hi.

Deine Klasse Speicher stellt einen Mutex dar. Seine Operationen Ablegen() und Holen() sind atomar, da sie als synchronized markiert sind. Intern wird ein Monitor benutzt, das stimmt. Wichtig ist: Ein Mutex kann nur einen (!) Speicherplatz verwalten. Im Speicher kann also immer nur eine Kiste liegen. Es ist also nicht möglich, dass der Erzeuger mehr als eine Kiste im Voraus produziert. Eine weitere wichtige Info zum Verständnis ist: Beim Aufruf von wait() verlässt der Thread den Monitor in einer atomaren Operation. Wird ein Thread per notify() aufgeweckt, erhält er den Monitor in einer atomaren Operation zurück.

Angenommen, der Verbraucher startet zuerst. Er ruft Holen() auf und rennt in das wait(), weil frei == true gilt. Gleichzeitig verlässt der Thread den Monitor und wird aus der Liste rechenbereiter Threads entfernt, weil er ja blockiert ist.

Irgendwann rennt der Erzeuger los. Er produziert eine Kiste und ruft Ablegen() auf. Das kann er, weil der Monitor vom blockierten Thread freigegeben wurde. Er legt die Kiste ab, denn es gilt frei == true. Der folgende Aufruf an notify() signalisiert einem wartenden Thread, dass er wieder rechnen darf. Es dauert aber noch, bis er vom System auch wirklich aufgerufen wird. Auf einem Multicore-System könnte er zwar sofort drankommen, aber das geht nicht, weil der Erzeuger den Monitor immer noch besitzt. Nach der Rückkehr der Methode Ablegen() ist der Monitor frei.

Der Verbraucher-Thread darf jetzt fortfahren. Er bekommt den Monitor und dreht eine weitere Runde in der While-Schleife, wobei er aber free == false vorfindet und daher nicht erneut wartet. Er konsumiert die Kiste. Das folgende notify() bleibt ohne Wirkung, weil kein anderer Thread blockiert ist.

Es gibt noch zwei andere Varianten: 1: Der Erzeuger startet und ist exakt gleich schnell wie der Verbraucher (langweilig). 2: Der Erzeuger startet zuerst und ist schneller als der Verbraucher. Der Ablauf ist wie oben, nur dass die Warteoperationen umgekehrt sind.

Die wait()-Aufrufe (d.H. die Zeilen 19-27 in Erzeuger UND Verbraucher) können m.E. weg - sie dienen vermutlich nur dazu, dass alle Fälle mal auftreten. Beim Weglassen dürfte eigentlich keine NullPointerException kommen (muss ich mal testen), denn die Synchronisation findet in der Speicher-Klasse statt.

Das Erzeuger-Verbraucher-Problem wurde nicht von irgendwem theoretisch konstruiert (ok, doch), sondern es existiert auch in der Realität. Folgende Vorstellung: Ein Heuboden, 2 Arbeiter, nur eine Leiter. Einer muss frisches Heu hochschaffen, der andere altes runternehmen. Der Boden hat eine begrenzte Größe. Natürlich können nicht beide gleichzeitig auf der Leiter stehen. Außerdem darf der Boden nicht zusammenbrechen, wenn der, der Heu runternehmen soll, zu langsam ist oder nicht häufig genug die Leiter hochkommt. Einschränkung durch die Rahmenbedingungen: Der Boden kann nie leer werden.

In der Informatik erzeugt die Lösung dieses Problems große Performance-Vorteile: Üblicherweise ist das Produzieren und Konsumieren von Items sehr viel teurer als die Warteschlangenverwaltung (und sehr viel teurer als ein "new KISTE", z.B. ein Datenbankabruf, der Zeit braucht). Natürlich soll dabei das verarbeitende Programm nicht blockiert werden. Es läuft daher in einem separaten Thread, was aber zu Problemen führt, wenn beide parallel auf die Queue zugreifen.

Vielleicht musst du ja zu Lernzwecken deinen Sync von Hand machen.
Aber ich verwende für solche Dinge üblicherweise eine ConcurrentQueue.
Da übernimmt das Framework solche Dinge.

Trade schrieb:

Meinst Du den Arbeitsspeicher oder die Speicher-Klasse?

Mit "Speicher" meinte ich die Klasse SPEICHER im ersten Spoiler oben.

Trade schrieb:

Warum genau ist das so?

Er kann nur eine Kiste aufnehmen, weil er nur zwischen frei = true/false unterscheiden kann - die Haupteigenschaft des Mutex. Der Mutex ist ein Spezialfall eines sogenannten Semaphors, das genauso funktioniert, mit Hilfe eines Zählers aber mehrere Prozesse gleichzeitig tracken (hier: blockieren) kann. Genau genommen ist die 1-Kisten-Variante auch nur ein Spezialfall des Erzeuger-Verbraucher-Problems, weil eben nur eine Kiste möglich ist. Der allgemeine Fall erlaubt zum einen mehr als eine Kiste im SPEICHER und zum anderen beliebige, auch asymmetrische Anzahlen von Erzeugern und Verbrauchern.

Trade schrieb:

wenn der Verbraucher jetzt schneller ist, dann würde er ohne das wait() einfach durchrennen oder andernfalls den Monitor blockieren, sodass der Erzeuger keine Kiste im Speicher ablegen könnte

Wenn das wait() im Verbraucher fehlt, kommt es darauf an, ob der Erzeuger vorher einmal gelaufen ist oder nicht. Wenn ja, verarbeitet er die eine Kiste ohne Fehler, denn er würde eh nicht warten. Danach haben wir denselben Fall, als wäre der Erzeuger noch nicht gelaufen: Es gilt frei = true und der Verbraucher hat den Monitor. Den behält er aber unendlich lange, da der Erzeuger den Monitor nicht bekommt --> Deadlock.

Trade schrieb:

Aber von was wird das dann eig. wieder aufgeweckt? Weil das soll ja eig. autonom nur warten, unabhängig davon, was der Erzeuger macht.

Gute Frage - die Doku sagt dazu (Hervorhebungen von mir):

public final void wait(long timeout) throws InterruptedException
Causes the current thread to wait until either another thread invokes the notify() method or the notifyAll() method for this object, or a specified amount of time has elapsed.

Es geht also tatsächlich nur um die Zeit, da die enthaltende Methode nicht Teil des objekteigenen Monitors ist (kein synchronized!). Interessant, dass das trotzdem funktioniert. Die Doku sagt übrigens auch:

Synchronization is built around an internal entity known as the intrinsic lock or monitor lock.

Soll heißen: synchronized an einer Methode bedeutet nichts anderes als:


Das Ganze interferiert nicht mit dem SPEICHER, weil Erzeuger und Verbraucher zwei unabhängige Objekte sind. Die können sich selbst locken, so viel sie wollen, denn ihre Threads sind alleine.

Trade schrieb:

wenn man das komplette Warten und Benachrichtigen im Speicher rauslässt. Dann kam es bei uns zu einer Exception. Das lag halt daran, dass er dann wahrscheinlich versucht hat, was aus dem leeren Speicher zu holen.

Wenn auch die Schleife fehlt, dann ja. Der Verbraucher war schneller und hat nicht gewartet, bis der Erzeuger den Slot gefüllt hatte --> Fail.

Trade schrieb:

dass die Threads mehr oder weniger kommunizieren könne

Und genau in diese Kategorie fällt auch dieses ganze Thema: Interprozesskommunikation. Neben dem Mutex, der hier behandelt wird (ok, hier wird mit nem Monitor gecheatet, aber für den Schulbetrieb soll das mal erlaubt sein), gibts dann noch die erwähnten Semaphoren und Message Passing. Zu letzterem zählt dann sowas wie RPC, MPI, DCOM und wie sie alle heißen.

Trade schrieb:

Afaik nutzen Monitore ja intern auch Semaphoren.

Können sie, müssen sie aber nicht. Monitore basieren auf dem Konzept der Zustandsvariablen. Wie der Zugriff auf diese intern synchronisiert wird ist eine andere Frage. Kann ein Semaphor machen, muss aber nicht. Die Synchronisation ist sowieso vom System abhängig, weil die CPU den Lock-Mechanismus hardwareseitig unterstützen muss. Ohne Hardware-Support ist das Ganze ineffizient, weil busy waiting vonnöten ist; siehe en.wikipedia.org/wiki/Test-and-set.

Trade schrieb:

Prolaag und Verhoog nach Dijkstra

...sind das Grundprinzip eines Semaphors.

Trade schrieb:

Ein Monitor nutzt dann wohl intern eine Semaphore mit 'nem Counter von 1, oder?

Ein Semaphor mit MaxCount = 1 nennt man Mutex. Der Monitor ist nicht dasselbe, siehe oben. Er benutzt dieses Konzept nur. Siehe auch en.wikipedia.org/wiki/Monitor_(synchronization) - im Abschnitt "condition variable" steht direkt als erster Satz das, was du schon festgestellt hast:

For many applications, mutual exclusion is not enough.

--> "synchronized" alleine reicht nicht aus, man braucht auch wait() / notify().

Trade schrieb:

Message Passing

...ist einfach ein anderer Synchronisationsmechanismus. Der Unterschied liegt in der Art der Speicherorganisation: Shared vs. Distributed Memory (oder anders: Mehrere CPUs / Kerne auf einem Board vs. mehrere Rechner über Netzwerk verbunden). Aber das geht schon in Richtung verteiltes Rechnen

Trade schrieb:

Also im Wesentlichen geht es halt darum, dass die Daten, die man teilt und deren Zugriff einen kritischen Abschnitt darstellt, von den einzelnen Threads kommen und man gegenseitig warten muss, bis diese adäquat vorhanden sind.

Korrekt. Das Problem ist, dass eine Anweisung wie "x = x + 1" mehr als eine Rechenoperation ist (hier: x lesen, 1 addieren, x überschreiben). Zwischen jeder Teiloperation kann der Scheduler dazwischenfunken, wobei ein anderer Thread x ggf. verändert. Die Synchronisation verhindert genau das, indem sie die 3 Operationen unteilbar zusammenfasst.

Trade schrieb:

Also generell mit WaitHandles

In .NET musst du dich um das Lock-Target und die Events selbst kümmern. Das Äquivalent zum Java-Code wäre:


SyncLock object ... End SyncLock ist äquivalent zu Monitor.Enter(object) ... Monitor.Exit(object)