Re: [Chicken-users] recursive mutex-lock!

[Vincent Manis]

On 2008 Feb 26, at 16:04, Tobia Conforto wrote:

> Well, the value returned by mutex-state can be either:
>
> locked by this thread
>         In this case there can be no race condition, as we own
>         the mutex and nothing is going to take it away from us.
>
> locked by another thread
> abandoned
> not-abandoned
>         In these cases the mutex is not ours, therefore we don't care
>         if it's locked or not, or if any other thread locks or unlocks
>         it in a race condition, because we'll call mutex-lock! anyway.
>
> not-owned
>         This I can't tell, as I have no clue what not-owned means :-)
...
> My ¢2 analysis says you can get away without a conditional lock, if  
> you just ignore the existence of a not-owned state.

You are exactly right, Tobia, and my apologies to Daishi, I should  
know better
than to look at threaded code at 1am :-)

Just a couple of clarifications. A race condition can occur if you do  
a test
for *un*locked and then attempt to lock the mutex, but in this case,  
as Tobia
says, the lock will hold. The not-owned case can only occur if someone  
locks
the thread anonymously, which nobody ever does, and is yet another  
example of
how Posix threads are overengineered.

There is a way of making this code fail by writing incorrect code.  
Suppose a
signal handler (say for SIGALRM) unlocks the mutex just after the  
test. Then
the code will assume that the mutex is locked when it isn't.  
Fortunately,
signal handlers aren't allowed to do things like that, so it's a case  
one should
be aware of but not worry about.

Let me put in a plug for my favorite book on concurrent programming,  
Doug Lea's
_Concurrent Programming in Java_, which, despite the title and the  
fact that it's
in Addison-Wesley's Java series, is much more about concurrency than  
about Java.


-- v