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: Rainer Weikusat on 29 Oct 2009 08:42 David Schwartz <davids(a)webmaster.com> writes: > On Oct 28, 8:04�am, Noob <r...(a)127.0.0.1> wrote: >> >> If delete is called on a locked mutex, the function must return an error >> >> code to signal the error to the function's caller. > >> > That is, IMO, fundamentally busted behavior, unless it only means >> > locked by the calling thread. > >> Could you expand on /why/ you think it is busted behavior? >> (I need ammo to try to convince the library authors.) [...] > Basically, it means the library plans to use a mutex among threads > that cannot even agree on the lifespan of the mutex, and that's > nonsensical because, among other reasons, they have to agree on the > lifespan of what the data protects anyway. A more probable conjecture would be that the library uses the delete-operation to detect if a mutex has meanwhile been unlocked without blocking on it and another conjecture based on that and a short search of the as-always-inaccessible relevant documentation[*] would be that (at least some versions of) Windows behaves in this way. [*] In this particular case, determining if this might be so had required to manually read through the descriptons of no less than 16,000 defined 'system error codes' which, as far as I could determine, are not explicitly associated with the functions which might return them in any way.
From: Måns Rullgård on 29 Oct 2009 09:27 Noob <root(a)127.0.0.1> writes: > M�ns Rullg�rd wrote: > >> Noob wrote: >> >>> Please note that, although I was discussing this topic in light of a >>> POSIX OS, the proprietary OS I'm using (ST OS21) does not conform to >>> POSIX, AFAIK. >> >> I truly feel sorry you. > > Because I have to work with ST's platform? :-) > > You have some experience with their platforms, don't you? As little as I could get away with, but yes, I've used them. >> The sensible thing to do in your situation is >> to walk away and find something proper to work on. > > You think I should change jobs? :-) > > Would you believe me if I told you ST refuses to provide any support > whatsoever because they consider we are too low volume? I have no problem believing that. -- M�ns Rullg�rd mans(a)mansr.com
From: Chris M. Thomasson on 29 Oct 2009 14:38 "Noob" <root(a)127.0.0.1> wrote in message news:hcbsu6$ocf$1(a)aioe.org... > Chris M. Thomasson wrote: > >> Man! This sucks!! Anyway, I believe you could meet all the requirements, >> however, it's not going to be pretty. Here is what I hacked together for >> you so far: >> >> http://cpt.pastebin.com/f540aaef5 > > Thanks Chris, I'll take a hard look at it. Here is updated code which handles the case in which a thread tries to unlock a mutex that is locked by another thread: http://cpt.pastebin.com/f3044e915 It also fixes a race-condition I overlooked. The unlocking needs to be done under the protection of the hash lock. The previous code did not do this, which would allow a thread A to destroy the mutex just before a thread B unlocked it. Sorry about that non-sense! Anyway, I cannot seem to find any more issues. > Please note that, although I was discussing this topic in light of a > POSIX OS, the proprietary OS I'm using (ST OS21) does not conform to > POSIX, AFAIK. I am not sure as I am not really familiar with at operating system.
From: Chris M. Thomasson on 29 Oct 2009 14:42 DAMN IT! That post was intended to be a response to the following message: http://groups.google.com/group/comp.programming.threads/msg/40f8d124cd038419 GRRR!!! I need coffee! ;^(....
From: Chris M. Thomasson on 29 Oct 2009 14:23
"Rainer Weikusat" <rweikusat(a)mssgmbh.com> wrote in message news:87eiome6dj.fsf(a)fever.mssgmbh.com... > "Chris M. Thomasson" <no(a)spam.invalid> writes: > > [...] > >> This is crowbar proof except for the case when a thread unlocks a mutex >> that >> it did not previously locked. > > The behaviour of such an operation is either undefined ('normal' and > 'default' mutexes) or it is an error ('errorcheck' and 'rescursive' > mutexes). Okay, I forgot about that because I very rarely use recursive mutexs; thank you! Here is updated code which takes this into account: http://cpt.pastebin.com/f3044e915 It also fixes a race-condition I overlooked. The unlocking needs to be done under the protection of the hash lock. The previous code did not do this, which would allow a thread A to destroy the mutex just before a thread B unlocked it. |