From owner-cvs-src@FreeBSD.ORG Wed Feb 28 18:01:30 2007 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31A3E16A400; Wed, 28 Feb 2007 18:01:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC2B13C46B; Wed, 28 Feb 2007 18:01:28 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l1SI1Ff1061172; Wed, 28 Feb 2007 13:01:24 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Greg 'groggy' Lehey" Date: Wed, 28 Feb 2007 10:06:17 -0500 User-Agent: KMail/1.9.1 References: <200702272309.l1RN9Xum011236@repoman.freebsd.org> <20070227235843.GA59138@xor.obsecurity.org> <20070228064334.GG8399@wantadilla.lemis.com> In-Reply-To: <20070228064334.GG8399@wantadilla.lemis.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702281006.18713.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 28 Feb 2007 13:01:25 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2679/Wed Feb 28 06:58:10 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Kris Kennaway Subject: Re: cvs commit: src/share/man/man9 sleep.9 X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2007 18:01:30 -0000 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