Zahn - Unix-Netzwerkprogramminerung mit Threads, Sockets und SSL

3.2 Synchronisation 125
97 exit( 0 );
98 }
28–48
65
77–94
In der Startfunktion des Verbraucher-Threads wird nun bei jedem Schleifendurchlauf
der zum gemeinsamen Puffer gehörende Mutex zunächst gesperrt
und am Ende wieder freigegeben. Im dazwischen liegenden, isolierten Bereich
(Zeile 33 bis Zeile 43) wird der gemeinsame Datenpuffer gelesen und geändert.
Durch den gegenseitigen Ausschluß mit dem Erzeuger-Thread erfolgt der Zugriff
auf diese Ressource exklusiv. Selbstverständlich müssen sich auch alle
anderen Threads dieses Prozesses dazu verpflichten, das Protokoll (Sperren
des Mutex, Zugriff auf die Daten, Freigabe des Mutex) strikt einzuhalten.
Andernfalls wird der vereinbarte Verhaltenskodex nicht eingehalten, der exklusive
Zugriff auf die gemeinsam genutzten Daten ist nicht mehr gewährleistet
und eine Race Condition wäre erneut gegeben.
In der Startphase des Programms ist die Initialisierung der Mutex-Variable
hinzugekommen. In den meisten Fällen werden Mutex-Variablen gleich zu Beginn
der main()-Funktion initialisiert, insbesondere vor dem Start der ersten
Threads. Dies garantiert, daß die Mutexe auf jeden Fall bereit stehen, wenn
die ersten Threads zur Synchronisation auf die Mutex-Variablen zugreifen.
Wie im Verhaltenskodex festgeschrieben, hält sich auch der Erzeuger-Thread
für den Zugriff auf den gemeinsamen Puffer genau an das vereinbarte Protokoll.
Als erstes wird der Mutex gesperrt. Ist der Thread im Besitz des Mutex’,
kann er in Ruhe einen neuen Datensatz in den Puffer einstellen. Im Anschluß
an diese Operation wird der Mutex wieder freigegeben und der Erzeuger-
Thread wartet auf die nächste Eingabe.
Durch die besprochenen Änderungen werden in Beispiel 3.5 Race Conditions
erfolgreich vermieden und das implementierte Verfahren arbeitet, ein faires
Scheduling zwischen Erzeuger und Verbraucher vorausgesetzt, in jedem Fall
korrekt. Allerdings weist auch diese Programmversion noch zwei Schwachstellen
auf, die es zu adressieren gilt:
1. Der Verbraucher-Thread rast in Erwartung eines neuen Datensatzes ohne
Unterbrechung durch seine Endlosschleife. Anstatt bei leerem Datenpuffer
auf einen neuen Datensatz zu warten, beendet der Thread die Schleife um
sofort einen neuen Versuch zu starten.
2. Der Erzeuger-Thread wartet zwar, bis ein neuer Wert eingegeben wird,
versucht dann aber ohne jegliche Geduld, den Wert im Datenpuffer abzulegen.
Ist der Puffer bereits voll, wird der Wert verworfen und der Anwender
zur erneuten Eingabe aufgefordert, anstatt darauf zu warten, daß der
nebenläufig arbeitende Verbraucher-Thread den nötigen Platz schafft.
Während der Verbraucher-Thread durch seinen Dauerlauf ”
lediglich“ sinnlose
CPU-Last erzeugt, ist das Verhalten des Erzeuger-Threads eine Zumutung