[Top][All Lists]
[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/
> ******************************