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)
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.
Thanks,
Marcus
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
