From: Rainer Weikusat on
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
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
"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
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
"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.