chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daishi Kato
Subject: Re: [Chicken-users] recursive mutex-lock!
Date: Wed, 27 Feb 2008 17:13:04 +0900
User-agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/21.4 Mule/5.0 (SAKAKI)

Thanks a lot Vincent and Toiba!

I was wondering if such a piece of code is already existed,
since recursive locking is fairly intuitive.
I also found chicken detects recursive locking as a dead lock,
and raises an error, but runs finely.

--daishi

At Tue, 26 Feb 2008 17:46:15 -0800,
Vincent Manis wrote:
> 
> 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
> 
> _______________________________________________
> Chicken-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/chicken-users
> 
> ******************************
>  XREA.COM -Free Web Hosting-
>  http://www.xrea.com/
> ******************************




reply via email to

[Prev in Thread] Current Thread [Next in Thread]