Date: Mon, 07 Aug 2000 23:21:48 +0100 From: Paul Richards <paul@originative.co.uk> To: dg@root.com Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, Alfred Perlstein <bright@wintelcom.net>, Matt Dillon <dillon@earth.backplane.com>, Mike Smith <msmith@FreeBSD.ORG>, Stephen McKay <mckay@thehub.com.au>, freebsd-current@FreeBSD.ORG, dillon@FreeBSD.ORG Subject: Re: Ugly, slow shutdown Message-ID: <398F367C.27DD39DA@originative.co.uk> References: <200008072149.OAA04253@implode.root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Greenman wrote: > > >In the particular case of sleeping though, a woken process does need to > >check the condition that it slept on because one of the other processes > >sleeping on that resource may have had a chance to run first and changed > >some state. So as a general rule, you shouldn't assume that everything > >is fine when you return from being asleep because it might not be. > > No, that's not true, and there are many examples in the kernel where a > bogus wakeup would lead to bad things happening. I recall some code in the > advisory locking code, and VM system, that assume that there is only one > wakeup event and that the thing causing it assures that certain other > things have occured before issuing it. That's just the way it has worked > since the dawn of time. I did say "as a general rule". If you know that "by design" nothing else is going to mess with what you're sleeping on before you wake up then you can make tighter optimisations but that's not the general case. There is such a thing as over optimisation though and for the sake of a simple if statement it is probably better to write code that is robust to changes made elsewhere in the system rather than squeeze every inch of performance out of the code, unless there's a real need to optimize in that particular area. Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?398F367C.27DD39DA>