Mutex ???
-
normale events laufen nur processintern und dienen meist der thread-synch.
Nope. Das stimmt nicht. Events spiegeln einen bestimmten Status wieder, signalisiert oder eben nicht. Ein Mutex hingegen wird von einem Thread in Besitz genommen (auch mehrmals) und wieder zurückgegeben und dient dadurch der Synchronisation.
-
hast du da jetzt nicht was mit der semaphore verwechselt ? ( mag mich auch irren )
rocknix ///
-
Mit Semaphoren kannst Du einer festgesetzten Zahl von Threads Zugriff erlauben. Das geht weder mit Mutexen noch mit Events und ich habe da auch nichts verwechselt. Oder meintest Du das noch irgendwie anders?
-
Events sind Kernel-Objekte und alle Kernel-Objekte (Ausnahme. Critical Sections) können Prozeßübergreifend verwendet werden.
Ein Mutex ist wie eine Art Staffelstab. Den kann immer nur einer haben. ->Der Mutext kann sich immer nur im Besitz eines Threads befinden.
Semaphoren benutzt man wenn man von einer Resource mehere Objekte hat (vgl. eine Kiste Äpfel). Aus der Kiste kann man sich solange was rausnehmen bis sie leer ist. Wenn die Kiste leer ist wechselt sie in den Zustand nicht signalisiert.
Für weitergehende Details empfehle ich ein Blick in den Richter.
-
... alle Kernel-Objekte (Ausnahme. Critical Sections) ...
Eine CriticalSection ist kein Kernel-Object, sondern eine einfache Daten-Struktur und ist aus genau diesem Grunde nicht Process-Übergreifend verfügbar. Lediglich das in der Struktur gehaltene Event-Handle (das treffenderweise 'LockSemaphore' genannt wird
) geht als Kernel-Object durch.
-
Eine CriticalSection ist kein Kernel-Object, sondern eine einfache Daten-Struktur und ist aus genau diesem Grunde nicht Process-Übergreifend verfügbar. Lediglich das in der Struktur gehaltene Event-Handle (das treffenderweise 'LockSemaphore' genannt wird ) geht als Kernel-Object durch.
In der 3. Ausgabe von Richter "MS Windows-Programmierung für Experten" steht in der Auflistung der Kernel-Objekte die Critical Section mit drin. Man kann sich nun drüber streiten ob es eins ist. Im Multiprozessor-Kernel von NT sind die als Mutexe impl.
Fest steht sie werden benutzt um den Zugriff auf eine knappe Resource zu serialisieren.
-
Im Multiprozessor-Kernel von NT sind die als Mutexe impl.
Das ist nun was völlig neues. Wo kann ich das nachlesen? Quelle bitte! Es werden doch nur die nops durch das Lock-Präfix ersetzt?
[edit]
FYI: Das das nur eine Struktur ist, siehst Du in <winnt.h>.
[/edit][ Dieser Beitrag wurde am 08.05.2003 um 20:02 Uhr von -King- editiert. ]
-
Ein Mutex ist wie eine Art Staffelstab. Den kann immer nur einer haben. Der Mutext kann sich immer nur im Besitz eines Threads befinden.
und wo bitte ist dann der unterschied zu einem event ?
rocknix ///
-
und wo bitte ist dann der unterschied zu einem event ?
Ein Event kann man nicht 'haben'. Da gibt es eben nur die zwei Zustände. Alle Threads können das Event fröhlich von dem einen in den anderen Zustand wechseln lassen.
Ein Mutex hingegen geht direkt in den Besitz eines Threads über. Und da bleibt es solange, bis entweder der Thread endet oder aber er das Mutex wieder freigibt.
Unterschiede gibt es auch beim Warten. Bei Events ist es so, daß der nächste zuteilungsfähige Thread drankommt (ich spreche von Auto-Reset-Events). Beim Mutex wird die Warteliste in einem FIFO organisiert. Der erste Thread, der auf das Mutex wartet, bekommt es dann auch zuerst.
-
-King- schrieb:
Ein Event kann man nicht 'haben'. Da gibt es eben nur die zwei Zustände. Alle Threads können das Event fröhlich von dem einen in den anderen Zustand wechseln lassen.
Ein Mutex hingegen geht direkt in den Besitz eines Threads über. Und da bleibt es solange, bis entweder der Thread endet oder aber er das Mutex wieder freigibt.
Unterschiede gibt es auch beim Warten. Bei Events ist es so, daß der nächste zuteilungsfähige Thread drankommt (ich spreche von Auto-Reset-Events). Beim Mutex wird die Warteliste in einem FIFO organisiert. Der erste Thread, der auf das Mutex wartet, bekommt es dann auch zuerst.
ich stimme dir jetzt mal prinzipiell zu. Allerdings können Mutexe auch prioritätsgesteuert sein. Also FIFO ja, solange alle Prozesse (für den Mutex) die gleiche Prio haben. Sonst wird die queue neu "sortiert".
-
Mutex = Mutual Exclusive Semaphore = Gegenseitig Ausschliessendes Wartesignal (der Begriff "Semaphore" stammt aus dem Eisenbahnbereich).
Genauso, wie ein Gleis immer nur von einem Zug passiert werden kann, sollten Daten immer nur von einem Thread gleichzeitig bearbeitet werden. Sonst kommt es zum Crash ...
Ein Mutex verhindert also, dass zwei nebenlaeufige Programmteile (Threads) auf dieselben Daten zugreifen.
Hat ein Mutex einen Besitzer, und will ein anderer Nebenlauf des Programms das Mutex in Besitz nehmen, muss er warten. Dies erledigt das Betriebssystem automatisch, wenn man die Mutex-Funktionen richtig verwendet.
CreateMutex() zum Erstellen eines Mutex, WaitForSingleObject() zum Inbesitznehmen oder Pruefen eines Mutex, ReleaseMutex() zum Freigeben/Entsperren eines Mutex, sowie CloseHandle() zum Schliessen eines Mutex, wenn es nicht mehr gebraucht wird.
Mutexe sind das wichtigste Mittel zur Thread-Synchronisation.
Events (Ereignisse) dienen dazu, bestimmte Ereignisse zu signalisieren.
Windows kennt auch "Semaphore", die allerdings als Zaehlvariable implementiert sind, was Programmierer mit anderem Background etwas verwirren duerfte.
Ein Blick ueber den Tellerrand:
- UNIX-aehnliche Systeme haben zwar Mutexe, aber keine Events. Diese muss man mittels sogenannter "Bedingungs-Variable" (condition variables) nachbilden.
- AmigaOS nennt Events Signale, und Mutexe Signal-Semaphoren.