WaitForSingleObject failed trotzdem ReleaseMutex? [gelöst]

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut
Antworten
laz847
Beiträge: 114
Registriert: Mi 18. Jun 2014, 16:39

WaitForSingleObject failed trotzdem ReleaseMutex? [gelöst]

Beitrag von laz847 »

Hallo zusammen, kurze Frage, bin mir da noch unsicher:

Code: Alles auswählen

mtx_res := WaitForSingleObject(mmf[cid].mtxh , 1000);
 
 if(mtx_res <> 0) then begin
  log('WaitForSingleObject failed usw....');
  ReleaseMutex(mmf[cid].mtxh); // (1) ist dieses ReleaseMutex hier falsch?
  exit;
 end;  
 
arbeiten....
 
ReleaseMutex(mmf[cid].mtxh); // (2) 
mtx_res kann ja WAIT_OBJECT_0, WAIT_ABANDONED, WAIT_TIMEOUT, WAIT_FAILED sein, muss man da aufsplitten und in bestimmten Fällen evtl. ReleaseMutex nutzen oder reicht das (2)?
Zuletzt geändert von laz847 am Fr 3. Apr 2015, 15:46, insgesamt 1-mal geändert.

marcov
Beiträge: 1102
Registriert: Di 5. Aug 2008, 09:37
OS, Lazarus, FPC: Windows ,Linux,FreeBSD,Dos (L trunk FPC trunk)
CPU-Target: 32/64,PPC(+64), ARM
Wohnort: Eindhoven (Niederlande)

Re: WaitForSingleObject failed trotzdem ReleaseMutex?

Beitrag von marcov »

Das MSDN Vorbild macht nur releasemutex wenn WAIT_OBJECT_0: https://msdn.microsoft.com/en-us/librar ... 85%29.aspx

Wird ein Mutex wirklich genutzt (IAW über Prozessgrenze ?), sonst kann man besser CriticalSection anwenden?

laz847
Beiträge: 114
Registriert: Mi 18. Jun 2014, 16:39

Re: WaitForSingleObject failed trotzdem ReleaseMutex?

Beitrag von laz847 »

Wird ein Mutex wirklich genutzt (IAW über Prozessgrenze ?), sonst kann man besser CriticalSection anwenden?
Keine Ahnung was IAW bedeutet (steh ich aufm Schlauch?) aber ja, die Mutex schützt ein Memory-Mapped-File welches durch eine andere Software erstellt, beschrieben und verändert wird. DANKE das Du mitdenkst :D
Das MSDN Vorbild macht nur releasemutex wenn WAIT_OBJECT_0:
Ich weiß :D! Und da denkt man als Erstes, warum guckt der Idiot nicht einfach nach, hab ich aber :

WAIT_OBJECT_0 - logisch hier muss ReleaseMutex folgen

WAIT_TIMEOUT, WAIT_FAILED - logisch, keine Mutex - kein Release

WAIT_ABANDONED - The thread got ownership of an abandoned mutex >> Der Thread hat das Eigentum an einem verlassenen Mutex

Ich hab jetzt absichtlich mal ganz einfach nachgefragt, ohne vorher etwas dazu zu sagen.

Aber wenn ich da lese "Eigentum an einem verlassenen Mutex", klingt das irgendwie als wenn man da auch nen Release machen müsste / sollte?
Zuletzt geändert von laz847 am Fr 3. Apr 2015, 15:45, insgesamt 12-mal geändert.

laz847
Beiträge: 114
Registriert: Mi 18. Jun 2014, 16:39

Re: WaitForSingleObject failed trotzdem ReleaseMutex?

Beitrag von laz847 »

Gerade gefunden, hatte ich wohl doch den richtigen Riecher oder?

Bug in mutex handling for abandoned mutexes in MSW code >> BUG Meldung aus 2009

http://trac.wxwidgets.org/ticket/10236
The problem is the handling of WAIT_ABANDONED. According to the documentation of WaitForSingleObject WAIT_ABANDONED is returned when the thread which owns the mutex terminates without releasing it. When this occurs WaitForSingleObject returns WAIT_ABANDONED and grants ownership to the new thread. The reason it does this rather than simply returning WAIT_OBJECT_0 is so that the caller is aware that resources protected by the mutex may not have been tidied up, there may be data corruption etc.

This will indeed always succeed and return WAIT_OBJECT_0. However it will also increment the reference count on the mutex and so the mutex will need two subsequent calls to ReleaseMutex to release it. However, it's only going to get one and so deadlock will ensue.
case WAIT_OBJECT_0, WAIT_ABANDONED:
// ok
break;
Ach verdammt, ich hab natürlich bevor ich gefragt hatte nachgesehen - aber nicht in den Kommentaren :roll: Guckt mal in der MSDN unten in die Kommentare! https://msdn.microsoft.com/en-us/librar ... 85%29.aspx
WAIT_ABANDONED
The example code does have a suboptimal way of handling WAIT_ABANDONED. The calling thread does have ownership of the mutex, and it should release it, or no other thread will be able to acquire it until the thread exits, and leaves it once again abandoned. The example in this case should be more clear indicating that the calling thread does own it. It might be nice if it indicated some addition checks to see if the shared resource is in a consistent state, before proceeding with access to the shared resource.

Antworten