Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> On Thu, Jul 05, 2001 at 08:57:15AM -0700, Thomas Bushnell, BSG wrote:
> > Marcus Brinkmann <[EMAIL PROTECTED]> 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. :)
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
