http://groups.google.com/group/comp.programming.threads?hl=en
comp.programming.threads@googlegroups.com
Today's topics:
* Library requirement for mutex destroy - 13 messages, 5 authors
http://groups.google.com/group/comp.programming.threads/t/4a94e9df8d2f3e22?hl=en
==============================================================================
TOPIC: Library requirement for mutex destroy
http://groups.google.com/group/comp.programming.threads/t/4a94e9df8d2f3e22?hl=en
==============================================================================
== 1 of 13 ==
Date: Wed, Oct 28 2009 7:26 pm
From: Eric Sosman
Noob wrote:
> [...]
> I have no such freedom. I must use that proprietary library.
> It is a MAFIAA requirement (DVB Conditional Access).
The only MAFIAA references I find are to the merger of
the Motion Picture Association of America (MPAA) with the
Recording Industry Association of America (RIAA) to form the
Music And Film Industry Association of America (MAFIAA). The
merger was announced on April First, 2006. The date and the
acronym suggest some amount of spoofery ...
And DVB must be either the Democratic Voice of Burma or
something to do with Victoria Beckham, aka Posh Spice.
--
Eric Sosman
esosman@ieee-dot-org.invalid
== 2 of 13 ==
Date: Thurs, Oct 29 2009 3:40 am
From: Noob
Eric Sosman wrote:
> Noob wrote:
>
>> I have no such freedom. I must use that proprietary library.
>> It is a MAFIAA requirement (DVB Conditional Access).
>
> The only MAFIAA references I find are to the merger of
> the Motion Picture Association of America (MPAA) with the
> Recording Industry Association of America (RIAA) to form the
> Music And Film Industry Association of America (MAFIAA).
Right. http://en.wiktionary.org/wiki/MAFIAA
> The merger was announced on April First, 2006. The date and
> the acronym suggest some amount of spoofery ...
One might call it a caricature ;-)
> And DVB must be either the Democratic Voice of Burma or
> something to do with Victoria Beckham, aka Posh Spice.
Sorry for the acronym soup.
http://en.wikipedia.org/wiki/Digital_Video_Broadcasting
http://en.wikipedia.org/wiki/Conditional_access
== 3 of 13 ==
Date: Thurs, Oct 29 2009 4:06 am
From: Noob
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.
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.
== 4 of 13 ==
Date: Thurs, Oct 29 2009 5:23 am
From: Rainer Weikusat
"Chris M. Thomasson" <no@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).
== 5 of 13 ==
Date: Thurs, Oct 29 2009 5:30 am
From: Måns Rullgård
Noob <root@127.0.0.1> writes:
> 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.
>
> 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. The sensible thing to do in your situation is
to walk away and find something proper to work on.
--
Måns Rullgård
mans@mansr.com
== 6 of 13 ==
Date: Thurs, Oct 29 2009 5:40 am
From: Noob
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?
> 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?
Sigh^2
== 7 of 13 ==
Date: Thurs, Oct 29 2009 5:42 am
From: Rainer Weikusat
David Schwartz <davids@webmaster.com> writes:
> On Oct 28, 8:04 am, Noob <r...@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.
== 8 of 13 ==
Date: Thurs, Oct 29 2009 6:27 am
From: Måns Rullgård
Noob <root@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@mansr.com
== 9 of 13 ==
Date: Thurs, Oct 29 2009 11:38 am
From: "Chris M. Thomasson"
"Noob" <root@127.0.0.1> wrote in message news:hcbsu6$ocf$1@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.
== 10 of 13 ==
Date: Thurs, Oct 29 2009 11:42 am
From: "Chris M. Thomasson"
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!
;^(....
== 11 of 13 ==
Date: Thurs, Oct 29 2009 11:23 am
From: "Chris M. Thomasson"
"Rainer Weikusat" <rweikusat@mssgmbh.com> wrote in message
news:87eiome6dj.fsf@fever.mssgmbh.com...
> "Chris M. Thomasson" <no@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.
== 12 of 13 ==
Date: Thurs, Oct 29 2009 11:27 am
From: "Chris M. Thomasson"
"Noob" <root@127.0.0.1> wrote in message news:hcbsu6$ocf$1@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.
== 13 of 13 ==
Date: Thurs, Oct 29 2009 3:25 pm
From: "Chris M. Thomasson"
"Chris M. Thomasson" <no@spam.invalid> wrote in message
news:hccn64$fi5$2@news.eternal-september.org...
>
> "Noob" <root@127.0.0.1> wrote in message news:hcbsu6$ocf$1@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.
I have implemented the algorithm in Relacy Race Detector:
http://relacy.pastebin.com/f227e4245
Relacy likes it! So, this scheme works. BTW, what does the interface look
like for the ST OS21 operating system? If it's compatible, then you have a
complete solution which will conform to the libraries rules.
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.programming.threads"
group.
To post to this group, visit http://groups.google.com/group/comp.programming.threads?hl=en
To unsubscribe from this group, send email to comp.programming.threads+unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.programming.threads/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
No comments:
Post a Comment