[Top][All Lists]

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

Re: a recursive lock prototype

From: Thomas Bushnell, BSG
Subject: Re: a recursive lock prototype
Date: 06 Jul 2001 10:08:25 -0700
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Marcus Brinkmann <brinkmd@master.debian.org> writes:

> On Thu, Jul 05, 2001 at 08:57:15AM -0700, Thomas Bushnell, BSG wrote:
> > Marcus Brinkmann <brinkmd@master.debian.org> writes:
> > 
> > > We agreed, in an inspiring coordinated coding effort, on the following
> > > implementation (thanks to Johannes, Neal, Moshe and Rene):
> > 
> > No, that still has a race condition as follows.  We begin in the fully
> > unlocked state.
> > 
> > THREAD 1                        THREAD 2
> > 
> > Start recursive_lock
> > Read RL->locking_thread
> >                 Context Switch
> >                                 Start recursive_lock, function finishes     
> >    
> >                 Context Switch
> > Check RL->locking_thread
> >   it seems to match, and the lock
> >   incorrectly succeeds.
> > 
> > You need some kind of guard around this structure!
> How can the check after the second context switch succeed?
> Thread 2 will change the value from MACH_PORT_NULL to the port name
> of it's thread port, neither matches the port name of thread 1.
> So the evaluation of the if condition is a constant
> (rl->locking_thread == thread)

It's already read the name out of RL.  That "check" is just the
comparison between two registers in Thread 1's local context.  The
value it would check was frozen when it did the memory read before the
first context switch.

> I found it really weird that no guard is needed, but actually refcount
> is guarded by the mutex, as are all writers of the locking_thread.
> The only unguarded reader of that is the above if, and we considered 
> all cases we could think of and came to the conclusion that it is robust.

You were wrong, sorry to say. :)

reply via email to

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