Date: Wed, 28 Feb 2007 10:06:17 -0500 From: John Baldwin <jhb@freebsd.org> To: "Greg 'groggy' Lehey" <grog@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: cvs commit: src/share/man/man9 sleep.9 Message-ID: <200702281006.18713.jhb@freebsd.org> In-Reply-To: <20070228064334.GG8399@wantadilla.lemis.com> References: <200702272309.l1RN9Xum011236@repoman.freebsd.org> <20070227235843.GA59138@xor.obsecurity.org> <20070228064334.GG8399@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 28 February 2007 01:43, 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.
Actually, sleepq's can have an assert to panic if you don't use the same
interlock always for a given active sleep address which can go a ways to
addressing the issue. I think the real fix is condition variables as they
allow for a much clearer statement of intent in the code anyway. To address
another point in this thread though: using wakeup() doesn't really "fix" the
issue either unless you properly sleep doing something like:
while (need_to_sleep) {
[tm]sleep(...)
}
If you just do a single sleep() then a wakeup for that address for an
unrelated events can also result in headaches. The real fix is to simply not
abuse sleep addresses for multiple events.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200702281006.18713.jhb>