Frage Mutex / lock verwendung?
-
der vorteil bei diesem szenario, bei B wird die ressoure garantiert wieder frei gelassen...
A:
{objMutex.Acquire(); //do something return; objMutex.Release(); }B:
{ Lock objLock(objMutex); //do something return; }
-
Genau, oder es könnte irgendwo zwischen Aquire und Release eine Exception geworfen werden (auch von weiter unten). Also ich würde auch sagen, dass die Lock-Methode besser ist, wenn man einen normalen Scope-Lock braucht.
-
naja würde aber da eine asserstion austreten, würde auch der Lock versagen oder?
-
BorisDieKlinge schrieb:
der vorteil bei diesem szenario, bei B wird die ressoure garantiert wieder frei gelassen......
Stimmt natürlich ... ist aber relevanter, wenn Exceptions fliegen, weil man ein "versehentliches return" noch relativ einfach findet/vermeiden kann. Wenn aber irgendeine genutzte Funktion (am Besten von "fremd" programmiert, nicht als Source verfügbar und "versteckt" wie ein Konstruktor oder ein operator) eine Exception wirft (am Besten undokumentiert), hat man echte Schwierigkeiten.
Ehrlich gesgt: Ich sehe gar keinen Vorteil von Variante A ggü. Variante B.
Gruß,
Simon2.
-
BorisDieKlinge schrieb:
naja würde aber da eine asserstion austreten, würde auch der Lock versagen oder?
Du sprichst mir unbekannte Sprachen ....
Warum sollte ein "Lock versagen", wenn eine Exception fliegt ? Und was haben "assertions" damit zu tun ? ...Gruß,
Simon2.
-
sorry ich mein damit, wenn eine unbehandelter fehler ohne exzeptions da auftritt wird das lock objekt nicht zerstört.. man muss definitf mit dem try /catch gedöns arbeiten
-
BorisDieKlinge schrieb:
sorry ich mein damit, wenn eine unbehandelter fehler ohne exzeptions da auftritt wird das lock objekt nicht zerstört.. man muss definitf mit dem try /catch gedöns arbeiten
Wenn ein unbehandelter Fehler (
unbehandelte Exception oder Assertion) fliegt, ist Dein Programm sowieso zuende. Da macht auch ein try/catch nichts mehr. In allen anderen Fällen wird der Destruktor beim Verlassen des Scope aufgerufen.
-
BorisDieKlinge schrieb:
sorry ich mein damit, wenn eine unbehandelter fehler ohne exzeptions da auftritt wird das lock objekt nicht zerstört.. man muss definitf mit dem try /catch gedöns arbeiten
OK, jetzt verstehe ich wenigstens, welchen Denkfehler Du gemacht hast.
Wie Lord schon gesagt hat: Das geht schon so.Gruß,
Simon2.
-
Was soll das überhaupt sein: ein unbehandelter Fehler?
-
Nur mal am Rande: In der ATL/MFC werden deshalb die Objekte (Mutexe, Critical Sections etc.) in eigenen Klassen gehalten, die nichts mit der Verwendung, also dem Lock zu tun haben. Dafür gibt es eine universelle CSingleLock/CMultiLock Klasse die den Lock selbst verwaltet.
RAII ist dadurch gewährleistet!
