Re: [9fans] sleep/wakeup bug?

[Russ Cox <rsc@swtch.com>]

>> assuming a tight 1:1 coupling between sleep and
>> wakeup is a recipe for trouble.  even if your change
>> fixes one possible race (i didn't bother to see what changed),
>> you still have to deal with
>
> the point of sleep/rendezvous is tight coupling, no?

no, it's not 1:1.

> the change was to move the ready() to after the rendezvous
> lock was dropped.  therefore the sleeper knows the rendezvous
> is not locked by the event that woke him.  if one can assert
> that each sleep has exactly one wakeup (as is often the case
> for rpc-style programming), then that is enough to know
> the rendezvous can be retired.

that's only true if the sleep sleeps.
if sleep checks f(arg) and finds it to be true, then it will not
sleep, and the subsequent wakeup will happen after sleep
returns (and be a no-op, unless the memory has been freed).

> if not a tight coupling, what kind of coupling would you
> think is appropriate?  when would you think it would be
> fair to recycle the rendezvous?  10s?  :-)  what idiom do
> you think would be appropriate for such a case?

it is appropriate to reuse the memory when you know that
no cpu is still referring to it.  you can deal with the main procs.
interrupt handlers are the wildcard.  put an ilock around the table
where the pointer to it is kept, and only use the memory
(from an interrupt handler) while inside the ilock.

russ