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: Eric Sosman on 1 Nov 2009 15:59 Rainer Weikusat wrote: > Eric Sosman <esosman(a)ieee-dot-org.invalid> writes: > >> Rainer Weikusat wrote: >>> [...] >>> I assume that the library uses 'delete' to emulate 'trylock' > > [...] > >> You may be right about the Windows origin of the nonsense >> specification, but I still cannot understand how a delete >> could be used in a trylock emulation. If you delete the mutex >> and are told "No, it's locked," fine: Your pseudo-trylock can >> report that the mutex was locked and hence not acquirable.[*] >> But what if the deletion succeeds? You then know that the >> mutex wasn't locked, but what good does it do you? >> You can't now lock it, because it no longer exists. > > If it is now impossible to lock the mutex which no longer > exists, the intent was quite obviously not to lock the mutex, only to > determine that a particular thread has unlocked a particular mutex, > presumably, after having completed some related task. In what sense does that "emulate `trylock'?" >> (Any any other thread that was about to lock it -- or delete it -- >> is in deep trouble, too.) > > As obviously, no such 'other thread' may exist. If it is possible that the delete operation finds the mutex locked, it follows that some thread somewhere has a reference to the mutex. (Or "had" a reference to the mutex, locked it, and then leaked the reference, in which case the mutex can never be unlocked or deleted by anybody, ever.) If a thread other than the deleter has a reference to the mutex, that thread might use the reference to attempt a lock or delete or other operation (if there are any in this library). There is no way inherent in the mutex to prevent the other thread from making use of its reference. There are other ways (program conventions or protocols) to do so, but if it is possible for delete to find the mutex locked, it is clear that no such protocols are operating. If the deleting thread is the only holder of a reference and finds the mutex locked, either the deleter itself holds the lock or the the thread that locked it has leaked its reference as described above. If the deleter holds the lock it is just barely possible that the operation might make sense, but it can't be a trylock emulation (because it never acquires the mutex, not even when the mutex is available). > Something which obviously doesn't make sense might simply be > wrong. As I wrote in the first paragraph: Since 'destruction of the > mutex' is a side effect of such a probe-operation, acquiring said > mutex can't be the objective. That is, it's *not* a trylock emulation. > Determining information about a > particular mutex (and consequently, the state of a particular thread) > could. Determining what the state of affairs looked like one CPU cycle ago might be interesting for statistical purposes, but for nothing else. A destructive determination isn't good even for that much. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Måns Rullgård on 1 Nov 2009 16:01 David Schwartz <davids(a)webmaster.com> writes: > On Nov 1, 10:15�am, Rainer Weikusat <rweiku...(a)mssgmbh.com> wrote: > >> If it is now impossible to lock the mutex which no longer >> exists, the intent was quite obviously not to lock the mutex, only to >> determine that a particular thread has unlocked a particular mutex, >> presumably, after having completed some related task. > > Or before having started some related task. And if you have some kind > of synchronization other than the mutex that tells you the thread has > started the task, why wouldn't that same method tell you when it had > finished that task? > > My bet is someone just took whatever ratbag assortment of feature > there platform's mutexes happened to have, or that they thought their > platform had due to misunderstandings and confusions of various sorts, > and asked for that. I'd be curious to know what this library is. -- M�ns Rullg�rd mans(a)mansr.com
From: Rainer Weikusat on 2 Nov 2009 05:29 Eric Sosman <esosman(a)ieee-dot-org.invalid> writes: > Rainer Weikusat wrote: >> Eric Sosman <esosman(a)ieee-dot-org.invalid> writes: >> >>> Rainer Weikusat wrote: >>>> [...] >>>> I assume that the library uses 'delete' to emulate 'trylock' >> >> [...] >> >>> You may be right about the Windows origin of the nonsense >>> specification, but I still cannot understand how a delete >>> could be used in a trylock emulation. If you delete the mutex >>> and are told "No, it's locked," fine: Your pseudo-trylock can >>> report that the mutex was locked and hence not acquirable.[*] >>> But what if the deletion succeeds? You then know that the >>> mutex wasn't locked, but what good does it do you? >>> You can't now lock it, because it no longer exists. >> >> If it is now impossible to lock the mutex which no longer >> exists, the intent was quite obviously not to lock the mutex, only to >> determine that a particular thread has unlocked a particular mutex, >> presumably, after having completed some related task. > > In what sense does that "emulate `trylock'?" In the sense that it enables to check if a mutex is presently locked without blocking on it. Since I already wrote this in my first posting on this topic, I thought the restricted meaning was clear enough, especially taking into account that a delete operation cannot ever lock a mutex. [...] >> Determining information about a >> particular mutex (and consequently, the state of a particular thread) >> could. > > Determining what the state of affairs looked like one CPU > cycle ago might be interesting for statistical purposes, but > for nothing else. You have no information beyond what was posted about this library and therefore, the assumption that no such 'program conventions or protocols' will be in use seems unjustified: It is again one whose sole purpose is to construct an example which doesn't make sense, based on incomplete factual information.
From: Eric Sosman on 2 Nov 2009 07:40 Rainer Weikusat wrote: > Eric Sosman <esosman(a)ieee-dot-org.invalid> writes: >> Rainer Weikusat wrote: >>> Eric Sosman <esosman(a)ieee-dot-org.invalid> writes: >>> >>>> Rainer Weikusat wrote: >>>>> [...] >>>>> I assume that the library uses 'delete' to emulate 'trylock' >>> [...] >>> >>>> You can't now lock it, because it no longer exists. >>> If it is now impossible to lock the mutex which no longer >>> exists, the intent was quite obviously not to lock the mutex, [...] >> In what sense does that "emulate `trylock'?" > > In the sense that it enables to check if a mutex is presently locked > without blocking on it. [...] Ah! Not an emulation of trylock, then, but of tryl. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Chris M. Thomasson on 3 Nov 2009 00:51
"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. > Because of > this, I assume that the library uses 'delete' to emulate 'trylock' and > if this was true, your suggestion above would certainly not be a > helpful one. |