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>