Library requirement for mutex destroy
in [Unix Programming]
|
Prev: Xlib question - efficient way to get pixel value?
Next: Printing Back tracing information during run time
From: Chris M. Thomasson on 3 Nov 2009 00:56 "Chris M. Thomasson" <no(a)spam.invalid> wrote in message news:NnJHm.3$XH1.0(a)newsfe22.iad... > "Rainer Weikusat" <rweikusat(a)mssgmbh.com> wrote in message > news:87tyxeio0s.fsf(a)fever.mssgmbh.com... >> frege <gottlobfrege(a)gmail.com> writes: >>> On Oct 28, 9:27 am, Noob <r...(a)127.0.0.1> wrote: >>>> [ Cross-posted to c.p.t and c.u.p ] >> >> [...] >> >>>> But this library has specific requirements for the delete function: >>>> >>>> If delete is called on a locked mutex, the function must return an >>>> error >>>> code to signal the error to the function's caller. >> >> [...] >> >>> I basically agree with everyone else - the specs are stupid. But my 2 >>> cents anyhow: >>> >>> 1. just don't implement it, but say you did. ie have delete never >>> return an error. The error would only ever been seen in broken code >>> anyhow. >> >> I consider it likely that the library was implemented by someone >> familiar with (and only with) the Windows threading interfaces, >> because these happen to have a couple of the properties David Schwartz >> mentionend, especially, that it is impossible to declare 'mutex' >> objects residing in memory accessible to all and therefore, >> indiscriminately usable by all threads. A Windows mutex is a >> system-managed object and can only be used by threads which happen to >> have a copy of the handle. Further, there doesn't seem to be a trylock >> operation > > There is a try-lock for Windows mutexs: > > > WaitForSingleObject(..., 0); > > > > >> and I am fairly convinced that the CloseHandle function >> will detect an attempt to release a locked mutex and notify the caller >> of that (I could be wrong on all the details, though), since this >> would be in line with the 'child-safety precaution at any cost'-mindset >> which is so common among everything sprung from Redmond. > > No. Windows mutexs are robust. Therefore if a process dies while it hold's > one the next locker will receive `WAIT_ABANDONED'. This is essential for > creating robust lock-based inter-process synchronization schemes. [...] One other point. Windows named mutexs are reference counted using a inter-process strongly-thread safe counting algorithm. This is why any thread can acquire a reference to a named mutex that it did not previously own a reference to.
From: David Schwartz on 2 Nov 2009 21:48 On Nov 2, 9:56 pm, "Chris M. Thomasson" <n...(a)spam.invalid> wrote: > One other point. Windows named mutexs are reference counted using a > inter-process strongly-thread safe counting algorithm. This is why any > thread can acquire a reference to a named mutex that it did not previously > own a reference to. All named mutexes are this way. The "name" is, pretty much by definition, an index into a synchronized global table. DS
From: Rainer Weikusat on 3 Nov 2009 07:38
"Chris M. Thomasson" <no(a)spam.invalid> writes: > "Rainer Weikusat" <rweikusat(a)mssgmbh.com> wrote in message [...] >> and I am fairly convinced that the CloseHandle function >> will detect an attempt to release a locked mutex and notify the caller >> of that (I could be wrong on all the details, though), since this >> would be in line with the 'child-safety precaution at any cost'-mindset >> which is so common among everything sprung from Redmond. > > No. Windows mutexs are robust. Therefore if a process dies while it hold's > one the next locker will receive `WAIT_ABANDONED'. This is essential for > creating robust lock-based inter-process synchronization schemes. This doesn't seem to have any relation to the text I wrote. |