> in the case of this particular bug, i have at least 40µs
> grace and the change has held up for 12 hrs, where i
> could crash the machine in <5s before.
i don't know about you but if i were shipping code that
depended critically on not losing a race with a fast device,
it would keep me up at night.
what sape said. don't try to paper over this.
also what the sleep and wakeup paper says:
The code looks trivially correct in retrospect: all access to data
structures is done under lock, and there is no place that things
may get out of order. Nonetheless, it took us several iterations
to arrive at the above implementation, because the things that
can go wrong are often hard to see. We had four earlier
implementations that were examined at great length and only
found faulty when a new, different style of device or activity
was added to the system.
you can spend a lot of time chasing down bugs because
you are using sleep and wakeup incorrectly, or you can
use it correctly. "fixing" it is not something i would suggest
taking on.
sape also said that you can't dynamically allocate structures
with rendezvous in them, but that's not strictly true. you just
have to be careful, i.e. use a lock to make sure no cpu is
about to find or about to call wakeup on the structure
when you're about to free it. i believe the locking discipline
i described in my original mail works (use a lock instead of an
ilock if there's no interrupt involved).
i was going to point you at devmnt but devmnt looks buggy to me.
mountmux unlocks m before calling wakeup, which on first
glance looks like a mistake mitigated only by the fact that
mntfree only rarely frees r. or i could be missing something.
it's certainly much easier to use static rendez structures.
as presotto says in the thread richard mentioned,
the problem is not sleep vs wakeup. the responsibility
necessarily has to lie with the calling code, which is finding,
looking at, and possibly modifying the structure containing r
before it calls wakeup.
http://9fans.net/archive/?q=%27test-and-set+problem%27
>> p.s. not relevant to your "only one sleep and one wakeup"
>> constraint, but that last scenario also means that if you
>> are doing repeated sleep + wakeup on a single r, that pending
>> wakeup call left over on cpu2 might not happen until cpu1 has
>> gone back to sleep (a second time). that is, the first wakeup
>> can wake the second sleep, intending to wake the first sleep.
>> so in general you have to handle the case where sleep
>> wakes up for no good reason. it doesn't happen all the time,
>> but it does happen.
>
> this is probablly a bug lurking in many things.
it's not that hard to get this part right.
the simple rule is that you should call sleep in a loop
until the condition you are waiting for has happened.
(keep sleeping until your dreams come true?)
devmnt is a good example in this case.
seeing the loop when you read the code is also a
good reminder that sometimes sleep never runs
at all.
russ
