Re: [9fans] sleep/wakeup bug?

[erik quanstrom <quanstro@labs.coraid.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.

i don't yet see why this assumption isn't a good one to have.
what is the argument against tightening it up?  i don't see it yet.

> > 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).

and that case is fine, too.  either way, we're "done".

> > 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.

since i know i'm done when the wakeup happens, the wakeup
itself is causing the trouble.  it starts the sleeper before releasing
the rendezvous lock.  so your solution would have me have an ilock
(with no interrupt in sight!) to protect rendezvous from itself?

why can't rendezvous carry its own water?

- erik