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.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message