Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Feb 2007 16:51:11 +0000 (GMT)
From:      Robert Watson <rwatson@FreeBSD.org>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        Greg Lehey <grog@freebsd.org>, cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/share/man/man9 sleep.9
Message-ID:  <20070227164537.P46064@fledge.watson.org>
In-Reply-To: <20070227113338.GA30955@deviant.kiev.zoral.com.ua>
References:  <200702270251.l1R2pfaT072096@repoman.freebsd.org> <20070227113338.GA30955@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070227164537.P46064>