At Mon, 25 Feb 2008 00:52:25 -0800, Vincent Manis wrote: > > On 2008 Feb 25, at 00:19, Daishi Kato wrote: > > > Hi, > > > > SRFI-18 states, > > > > The mutex primitives specified in this SRFI do not implement > > "recursive" mutex semantics; an attempt to lock a mutex that is > > locked implies that the current thread must wait even if the mutex > > is owned by the current thread > > > > so, I want a macro or procedure to support "recursive" mutex. > > Would be glad someone can note on it. > > > > Here's my macro, not sure if it works: > > Isn't there a similar code? > > > > (define my-mutex (make-mutex)) > > (define-macro (my-lock . body) > > `(let ([result #f]) > > (if (eq? (mutex-state my-mutex) (current-thread)) > > (set! result (begin ,@body)) > > ;;else > > (begin > > (mutex-lock! my-mutex) > > (set! result (begin ,@body)) > > (mutex-unlock! my-mutex))) > > result)) > > > I have actually never used the Chicken threading capabilities, but > with almost > any mutex code it's a safe bet that there's race condition. In this > case, is > it possible that the mutex could become locked between a false eq? > result and > the call of mutex-lock! ? > > I think recursive mutex locking almost always needs a conditional lock > operation.
Yes, that was my question, too. I was writing with a conditional lock for this, but wondering if it might be ok with this case of eq?ing with (current-thread). Any other comments? --daishi _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
