Re: cvs commit: src/share/man/man9 sleep.9

From: Robert Watson <rwatson_at_FreeBSD.org>
Date: Tue, 27 Feb 2007 16:51:11 +0000 (GMT)
On Tue, 27 Feb 2007, Kostik Belousov wrote:

> On Tue, Feb 27, 2007 at 02:51:41AM +0000, Greg Lehey wrote:
>> grog        2007-02-27 02:51:41 UTC
>>
>>   FreeBSD src repository
>>
>>   Modified files:
>>     share/man/man9       sleep.9
>>   Log:
>>   Add warning about deadlocks created by use of wakeup_one.
>
> +.Fn wakeup_one
> +does not work reliably if more than one process is sleeping on the same
> +address;
> +in this case it is possible for an unrelated process to be woken.
> +This process will ignore the wakeup, and the correct process will never be
> +woken.
> +.Pp
>
> Is this a bug (that should be fixed), or some fundamental issue with 
> wakeup_one() ?

I'm also confused about this addition to the man page -- the sleep/wakeup 
model is premised on using a synchronization name space that we, for 
convenience, align with the possible pointer value name space.  In general, 
the approach works because we tie memory ownership to use of a synchronization 
address.  It sounds like wakeup_one() works entirely reliably, but that some 
piece of kernel code is sleeping on an address associated with memory it 
doesn't own.  This is not a bug on wakeup_one(), it is a bug in a consumer of 
the sleep(9) APIs.  I'd like to see this change backed out, and replaced with 
a note explicitly describing how the uniqueness of sleep/wakeup addresses is 
tied to memory allocation, and that improper use of the APIs can result in 
consumers behaving unreliably.

Robert N M Watson
Computer Laboratory
University of Cambridge
Received on Tue Feb 27 2007 - 16:51:12 UTC