Mutex: kleines Beispielprogramm
-
Wen meinst Du mit rumtrollen? Den berniebutt?
Was er geschrieben hat ist vom Prinzip her vollkommen richtig.
Er meinte, daß ein Mutex innerhalb der Threads (also innerhalb EINES Prozesses) ein wenig oversized ist.Ein Mutex ist in erster Linie dazu da, über mehrere Prozesse (also z.B. Applikationen) hinweg zu synchronisieren.
Innerhalb einer Applikationen reicht für die Synchronisation zwischen den Threads z.B. die Critical Sections aus.
Critical Sections ist wesentlich schlanker und ressourcenschonender als Mutex.
Siehe auch: http://www.c-plusplus.net/forum/viewtopic-var-t-is-186523-and-highlight-is-.html
Martin
-
guck dir bitte berniebutt beiträge an, dann weisste was ich meine.
-
ascda schrieb:
guck dir bitte berniebutt beiträge an, dann weisste was ich meine.
Wo ist Dein Problem, Unreg?
-
@Mmacher: Danke für die Erklärung,
Ein Mutex ist in erster Linie dazu da, über mehrere Prozesse (also z.B. Applikationen) hinweg zu synchronisieren.
heißt das, dass man mit Critical Section zwischen Prozessen nicht synchronisieren kann?
Fällt dir ein Grenzbeispiel ein, ab dem Critical Section nicht mehr funktioniert und man auf ein Mutex zurückgreifen muss?
Sonst würde ich ja nun, wie ich erfahren habe, immer wenn es geht Critical Section nehmen, da dies viel schneller läuft.grüße rom4o
-
ascda schrieb:
oh man kann irgendwer endlich mal diesen klappspaten aus dem forum verbannen? wie lange soll der hier noch rumtrollen?
Hahaha,
ich hatte den genau gleichen Gedanken
Mutex nur für Prozesse ... lach !
-
rom4o schrieb:
@Mmacher: Danke für die Erklärung,
Ein Mutex ist in erster Linie dazu da, über mehrere Prozesse (also z.B. Applikationen) hinweg zu synchronisieren.
heißt das, dass man mit Critical Section zwischen Prozessen nicht synchronisieren kann?
Fällt dir ein Grenzbeispiel ein, ab dem Critical Section nicht mehr funktioniert und man auf ein Mutex zurückgreifen muss?
Sonst würde ich ja nun, wie ich erfahren habe, immer wenn es geht Critical Section nehmen, da dies viel schneller läuft.grüße rom4o
Critical Section meint: Solange ein Thread dieses in Anspruch nimmt, wird das Task - Switching angehalten. Ein Mutex riegelt eine Funktion ab einer Waitroutine (WaitForSingleObject etc.) ab. Mutex regelt auch das Taskswitching nicht, sondern nur die Folge der Threads. Critical Section wirkt sofort bei EnterCriticalSection.
Einem Thread kann sehr wohl innerhalb einer Mutex gesicherten Funktion Rechnerzeit abhanden kommen. Genau dafür aber - damit das nicht passiert gibt es die Critical Section. Die hat nichts mit den Threads zu tun, sondern mit dem Taskscheduler. Es sichert einen Thread einfach ab, bis es diese Bereiche, wo es kritisch werden kann abgegessen hat ...
An und für sich ist das nicht schwer - es ist nur schwer zu beschreiben, in parallelen Zyklen.
Für das Grundverständnis von Prozess, Threads und dem Mulitasking empfehle ich immer das Buch: PC Intern von Data Becker.
Darin sind auch schöne Beispiele, wie diese Begriffe von Threadsynchronisation, die da sind: Mutex, Semaphore, Critical Sections, Event und andere schöne Objekte, greifen.
-
rom4o schrieb:
heißt das, dass man mit Critical Section zwischen Prozessen nicht synchronisieren kann?
Genau so ist es.
rom4o schrieb:
Fällt dir ein Grenzbeispiel ein, ab dem Critical Section nicht mehr funktioniert und man auf ein Mutex zurückgreifen muss?
Einen Mutex statt eines Critical Sections muß man dann nehmen, wenn man z.B. dafür sorgen möchte, daß die gleiche Applikation nur einmal zur gleichen Zeit gestartet werden darf. D.h. Ein Benutzer startet die gleiche Applikation (oder auch eine Kopie an einem anderen Pfad) nochmal, und über den Mutex weiß dann die zweite Applikation, daß er bereits schon von der ersten Applikation angelegt wurde. -> also ist hier eine Synchronisierung über Prozeßgrenzen hinweg nötig und damit ein Mutex (oder auch alternativ eine Semaphore).
Warum z.B. ein Mutex ressourcenfressender ist als Critical Section, liegt u.a. hauptsächlich daran, daß Mutexe sog. Kernel-Objekte sind (also salopp ausgedrückt, sehr tief im System verankert sind und deshalb mehr Prozessorzeit im Scheduler beansprucht), die Critical Sections dagegen "nur" User-Objekte sind.
Das alles (Mutexe, Semaphoren, Critical Sections, ...) ist ein eigenes Kapitel für sich, d.h. eine ordentliche Einarbeitung in dieses Thema ist sehr empfehlenswert (Buch oder Tutorials, siehe Links in meinem ersten Posting hier).
Alleine schon, daß Du mit dem Mutex Deine ersten "Gehversuche" erfolgreich unternommen hast ist schon mal ein sehr guter Schritt!
Martin
-
Nachtrag:
Ein recht einfach gehaltenes Tutorial (in deutsch!) möchte ich hier nicht vorenthalten:
http://www.jliforum.de/board/viewtopic.php?p=63665#63665Martin
-
Hallo Leute, danke für die Erklärungen,
hat sehr geholfen.
@Mmacher: Das Tutorial war sehr gut,
jetzt kenne ich mich auch mit Event und Semaphore aus.bb rom4o
-
CStern schrieb:
Mutex nur für Prozesse ... lach !
NIEMAND hat hier gesagt, Mutex-Objekte seien ALLEIN für Prozesse einsetzbar. Wie hier mehfach ausgeführt worden ist, gelten sie global im System und können somit auch nur in EINEM Prozess genutzt werden. Es fragt sich aber, warum soll man tun, wenn es speziell dafür Critical-Section-Objekte "SDK: ... slightly faster, more efficient ..." gibt.
Jeder kann seine Oma vom Flughafen auch mit dem LKW oder dem Moped abholen. Die Oma wird wahrscheinlich sagen: "Mein lieber Junge (mein liebes Mädchen), der Bus oder ein Taxi hätte es doch viel bequemer getan. Wir gehen jetzt erst einmal gemeinsam Kaffee trinken". Windows und die WinApi sind nicht so feinfühlig und können das auch nicht sein.
Rom4o: Du bist auf dem richtigen Weg bei einem komplexen Thema. Sobald für eine Synchronisation mehrere Prozesse (Applikationen) beteiligt sind, braucht man Mutex. Critical Section geht nur innerhalb eines Prozesses. Du brauchst zum Programmieren nicht den Rat der Oma!