Im zweiten Teil der unbestimmt langen Reihe
Multithreading in .NET befasse ich mich mit der
Klasse
System.Threading.Monitor.
System.Threading.Monitor
Der Monitor ist das Objekt, was sich bei genauerer Betrachtung hinter einem lock-Statement
verbirgt. Die Details dazu können
im
ersten Teil nachgelesen werden. Die Verwendung ist der eines lock-Statements sehr
ähnlich. Man verwendet den Monitor stets in Verbindung mit einem Objekt, welches verriegelt
werden soll. Der daraus resultierende IL-Code unterscheidet sich ebenfalls nicht von
dem eines lock-Statements.
privatevoid monitorNotationExample( object lockObject
) { Monitor.Enter( lockObject ); //Critical
Section: Do something Monitor.Exit( lockObject ); }Nach der Critical
Section muss allerdings im Gegensatz zum lock-Statement die Verriegelung explizit
wieder freigegeben werden. Dies macht den Monitor etwas fehleranfälliger als das lock-Statement.
Er hat allerdings auch einige ganz entscheidende Vorteile.
Vorteile der Klasse Monitor gegenüber lock
Die Klasse Monitor stellt neben der Funktion Enter noch die Funktion TryEnter bereit,
um eine exklusive Sperre für eine Critical Section zu bekommen. Die Funktion TryEnter
ist doppelt überladen und liefert jeweils einen Booleschen Wert zurück.
Der Aufruf der Funktion Monitor.TryEnter(Object) versucht, eine exklusive Sperre auf
das übergebene Objekt zu erlangen. Schlägt dies fehl, weil bereits ein anderer Thread
eine Sperre auf dieses Objekt hält, liefert die Funktion ein false zurück. Konnte
die Sperre erlangt werden, wird true zurückgegeben.
Die erste Überladung der Funktion mit dem zusätzlichen Parameter vom Typ Int32 dient
dazu, einen Timeout anzugeben. Dieser Timeout wird Anzahl der Millisekunden übergeben,
die maximal versucht werden soll, eine exklusive Sperre für das Objekt zu erlangen.
Wird zu einem beliebigen Zeitpunkt innerhalb der Zeitspanne die Sperre erlangt, gibt
der Aufruf true zurück. Wird der Timeout erreicht, kehrt der Aufruf mit false zurück.
Dieser Aufruf ermöglicht es also, eine bestimmte Zeit auf eine Sperre zu warten. Der
Rückgabewert muss also in jedem Fall ausgewertet werden. Außerdem muss man bei der
Verwendung der Funktion Monitor.TryEnter (Object, Int32) darauf achten, dass eine
geeignete Strategie vorhanden ist für den Fall, dass keine Sperre registriert werden
konnte.
Die zweite Überladung verlangt als zweiten Parameter keinen Int32, der die Anzahl
der Millisekunden für den Timeout angibt, sondern eine Zeitspanne vom Typ
System.TimeSpan.
Mit dieser zweiten Überladung ist es also möglich, die ersten beiden Funktionsaufrufe
nachzubilden. Entweder wird als Zeitspanne wirklich eine Zeitspanne übergeben, was
der ersten Überladung entspräche, oder es wird
Timeout.Infinite übergeben,
was dem Aufruf der Funktion Monitor.TryEnter(Object) entspräche.
Einige Beispiele
Um die Funktionsweise der einzelnen Methoden der Monitor-Klasse zu verdeutlichen,
werde ich einige Beispiele anführen. Beginnen wir mit einfacheren Verwendung des Monitors.
Wir nehmen einen Konsolenanwendung und erweitern diese mit der Klasse AsyncTest. In
dieser Klasse sind zwei Methoden enthalten, Sync1() und Sync2(). Beide Methoden greifen
auf dasselbe lock-Objekt zu. nämlich lock1.
class Program
{ staticvoid Main( string[]
args ) { AsyncTest test =new AsyncTest(
); Thread thread1 =new Thread( new ThreadStart(
test.Sync1 ) ); Thread thread2 =new Thread( new ThreadStart(
test.Sync2 ) ); thread1.Start( ); thread2.Start( ); Console.ReadLine( ); } } publicclass AsyncTest
{ privateobject lock1 =newobject(
); publicvoid Sync1(
) { Monitor.Enter(lock1); for ( int i = 1;
i <= 20; i++ ) { Console.Write( "1
{0}|", i ); Thread.Sleep( 20 ); } Monitor.Exit( lock1 ); } publicvoid Sync2(
) { Monitor.Enter( lock1 ); for ( int i = 1;
i <= 20; i++ ) { Console.Write( "2
{0}|", i ); Thread.Sleep( 20 ); } Monitor.Exit( lock1 ); } } Die
Ausgabe der beiden Threads erfolgt sequenziell, wie bereits im ersten Teil erklärt.
Schauen wir uns im nächsten Beispiel die Funktionsweise der Methode TryEnter an. Thread
2 in der Main-Routine führt nun die Methode Sync3 in der Klasse AsyncTest aus. Diese
versucht über den Aufruf von Monitor.TryEnter(lock1) eine Sperre auf das Objekt zu
bekommen.
class Program
{ staticvoid Main( string[]
args ) { AsyncTest test =new AsyncTest(
); Thread thread1 =new Thread( new ThreadStart(
test.Sync1 ) ); Thread thread2 =new Thread( new ThreadStart(
test.Sync3 ) ); thread1.Start( ); thread2.Start( ); Console.ReadLine( ); } } publicclass AsyncTest
{ privateobject lock1 =newobject(
); publicvoid Sync1(
) { Monitor.Enter(lock1); for ( int i = 1;
i <= 20; i++ ) { Console.Write( "1
{0}|", i ); Thread.Sleep( 20 ); } Monitor.Exit( lock1 ); } publicvoid Sync3(
) { if (
Monitor.TryEnter( lock1 ) ) { Console.WriteLine( Environment.NewLine +"Lock
achieved." ); Monitor.Exit( lock1 ); } else {
Console.WriteLine( Environment.NewLine +"Lock
cannot be achieved." ); } } } Ergibt:
Die Ausgabe zu diesem Beispiel entspricht der Beschreibung der Methode Monitor.TryEnter().
Es wird versucht, eine Sperre auf das übergebene Objekt zu registrieren. Schlägt dies
fehl, kehrt die Methode mit false zurück. Hätte eine Sperre registriert werden können,
wäre true zurückgegeben worden.
Betrachten wir das Verhalten der Methode Sync3() nun einmal mit Übergabe eines Timeouts.
Dieser soll 100 Millisekunden lang sein. Die neue Methode nennen wir Sync4() und verdrahten
sie in der Main-Methode auf den zweiten Thread:
publicvoid Sync4(
) { if (
Monitor.TryEnter( lock1, 100 ) ) { Console.WriteLine( Environment.NewLine +"Lock
achieved." ); Monitor.Exit( lock1 ); } else {
Console.WriteLine( Environment.NewLine +"Lock
cannot be achieved." ); } } 
Wie man sehen kann, kehrt die Methode Sync4 etwas später zurück als Sync3 im vorigen
Beispiel, kann jedoch immer noch keine Sperre registrieren. Betrachten wir die Funktion
Sync1 genauer, wird auch schnell klar, warum. Sie dauert bei 20 Schleifendurchläufen
mit jeweils einem Sleep von 20 Millisekunden mindestens 400 Millisekunden.
Setzen wir nun also den Timeout in Sync4 auf 1000 Millisekunden.
Wie man sehen kann, war der Timeout nun so lang, dass Sync1 vollständig abgearbeitet
und die Sperre freigegeben werden konnte, bevor der Timeout abgelaufen war. Der zweite
Thread konnte seine Sperre erfolgreich registrieren.
Platzierung der lock-Freigabe Monitor.Exit()
Wie man an Hand der Funktionen Sync3 und Sync4 erkennen kann, habe ich die Freigabe
der Sperre nicht an das Ende der Funktion gestellt, sondern an das Ende des Zweigs,
der bei erfolgreicher Registrierung der Sperre angesprungen wird. Wird nämlich die
Funktion Exit(object) auf ein Objekt aufgerufen, für welches der aufrufende Thread
keine Sperre registriert hat, bekommt man von der Runtime eine SynchronizationLockException
vor den Bug geknallt, die man dann behandeln darf.
Um dies zu vermeiden (und um logischeren Code zu schreiben) sollte man allerdings
den von mir gewählten Weg gehen und die Sperre nur dann freigeben, wenn sie auch wirklich
registriert wurde. Außerdem sollte man die Freigabe der Sperre in einem finally-Block
notieren, um auf alles vorbereitet zu sein. Auch wenn irgendwo innerhalb der Critical
Section eine Exception geworfen wird, wird so wenigstens die Sperre freigegeben und
die Chance erhöht, dass sich die Anwendung nicht in einem "Deadlock "aufhängt".
Die richtige Notation für den Monitor wäre also:
publicvoid Sync6(
) { if (
Monitor.TryEnter( lock1, 1000 ) ) { try { //Critical
section } finally {
Monitor.Exit( lock1 ); } } else { //else-Fall
behandeln } } Und wem bei der Betrachtung dieser Methode das C#
Keyword using in den Kopf kommt, der ist ganz nah bei dem, was sich die .NET-Entwickler
gedacht haben. Ändert man den Timeout von 1000 Millisekunden auf Timeout.Infinite
und lässt den else-Zweig weg, entspricht diese Methode dem lock-Statement. Womit nun
der Unterschied zwischen den drei Methoden Enter, TryEnter und Exit des Monitors sowie
dem lock-Statement hinreichend beschrieben sein sollte.
Fassen wir noch einmal zusammen:
-
Das lock-Statement wartet, bis es eine Sperre registrieren konnte. Die Freigabe der
Sperre erfolg in einem "finally"-Block (die geschweifte Klammer zu des lock-Blocks).
-
Enter versucht eine Sperre zu registrieren und kehrt sofort zurück. Entweder ist die
Sperre registriert (Rückgabe true) oder eben nicht (Rückgabe false). Auf jeden Fall
muss sich der Programmierer Gedanken im das Exception Handling machen.
-
TryEnter erweitert Enter um die Möglichkeit, einen bestimmten Zeitraum auf eine Sperre
zu warten. Entweder wird die Sperre in diesem Zeitraum registriert (Rückgabe true)
oder die Zeit läuft ab (Rückgabe false). Auch hier muss der Programmierer sich um
das Exception Handling selbst kümmern.
Im nächsten Teil werde ich die restlichen Funktionen der Klasse Monitor beleuchten:
Monitor.Wait(), Monitor.Pulse() und Monitor.PulseAll(). Bis dahin freue ich mich auf
Feedback und/oder Anregungen.
