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

[Kris Kennaway]

On Wed, Feb 28, 2007 at 05:13:34PM +1030, Greg 'groggy' Lehey wrote:
> On Tuesday, 27 February 2007 at 18:58:43 -0500, Kris Kennaway wrote:
> > On Tue, Feb 27, 2007 at 11:09:32PM +0000, Greg Lehey wrote:
> >
> >>> -function
> >>> -does not work reliably if more than one thread is sleeping on the same address;
> >>> -in this case it is possible for an unrelated thread to be woken.
> >>> -This thread will ignore the wakeup, and the correct process will never be
> >>> -woken.
> >>> +function does not work reliably if unrelated threads are sleeping on the same
> >>> +address.
> >>> +In this case, if a wakeup for one group of threads is delivered to a member of
> >>> +another group, that thread will ignore the wakeup, and the correct thread will
> >>> +never be woken up.
> >>> +It is the programmer's responsibility to choose a unique
> >>> +.Fa chan
> >>> +value.
> >>> +In case of doubt, do not use
> >>> +.Fn wakeup_one .
> >
> > I don't like this recommendation, since it directs the programmer to
> > introduce potentially serious performance bottlenecks at the expense
> > of clear thinking about their code to avoid introducing the bug in the
> > first place.
> 
> How would you address the case?  Recall that we're talking here about
> two different programmers, and you don't even know who the second one
> is.  It would be nice to have some mechanism like WITLESS to detect
> the problem, but I can't see how it would work.

Who are the two different programmers, you and who else? :-)

If there are parts of the FreeBSD kernel that are abusing a sleep
channel to create this situation, we should fix them.  If not, the
most that should be done in the FreeBSD manpage is to clearly explain
how not to introduce such a bug in a programmer's own code.

As far as I'm aware, nowhere else in our manpages do we provide advice
for the lazy programmer who cannot be bothered figuring out whether
his code is correct and who just wants an expedient hack in case it's
not.

Kris