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: frege on 30 Oct 2009 23:27 On Oct 28, 9:27 am, Noob <r...(a)127.0.0.1> wrote: > [ Cross-posted to c.p.t and c.u.p ] > > Hello, > > I'm using a proprietary library (no source code) which requires the user > to provide 4 mutex-related functions (create, delete, lock, unlock). > > AFAICT, if I were using a POSIX OS, I could make trivial wrappers around > > pthread_mutex_init > pthread_mutex_destroy > pthread_mutex_lock > pthread_mutex_unlock > > 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. > > However, the documentation for pthread_mutex_destroy explicitly states:http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex... > > """ > It shall be safe to destroy an initialized mutex that is unlocked. > Attempting to destroy a locked mutex results in undefined behavior. > """ > > This means that my delete function can't just call pthread_mutex_destroy > because I would invoke UB if the mutex is locked, and I wouldn't be able > to return the requested error code, right? > > So... Does this mean I have to keep track whether the mutex is locked? > (It would appear so.) > > Or perhaps I could mess with the OS code? (shudder) > > I'd like to tell the library author that it is unreasonable to impose > overhead on every lock and unlock operation just to catch an obvious (?) > programming error on delete. What do you think? > > N.B. the library requires mutex with recursive semantic. > > Regards. 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. or 2. ref count it: class ByTheSpecMutex { boost::shared_ptr<RealMutex> pmutex; public: error_code delete() { if (pmutex->count() > 1) return in_use_error; ... } }; Tony
From: Rainer Weikusat on 1 Nov 2009 04:37 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 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. 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.
From: Eric Sosman on 1 Nov 2009 11:45 Rainer Weikusat wrote: > 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 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. 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. 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. (Any any other thread that was about to lock it -- or delete it -- is in deep trouble, too.) [*] Actually, not even this much is true. The O.P. said the mutexes were supposed to be recursively lockable, so a mutex that is locked and hence not deletable might have been locked by the same thread, and hence acquirable despite the deletion failure. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Rainer Weikusat on 1 Nov 2009 13:15 Eric Sosman <esosman(a)ieee-dot-org.invalid> writes: > Rainer Weikusat wrote: >> 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. [...] >> Further, there doesn't seem to be a trylock >> operation 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 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. > (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. > [*] Actually, not even this much is true. The O.P. said > the mutexes were supposed to be recursively lockable, so a > mutex that is locked and hence not deletable might have been > locked by the same thread, and hence acquirable despite the > deletion failure. 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. Determining information about a particular mutex (and consequently, the state of a particular thread) could.
From: David Schwartz on 1 Nov 2009 15:20
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. DS |