[9front] Re: commit b3a26fb633f4649fc202b77c0184184b756960e7

[9front] Re: commit b3a26fb633f4649fc202b77c0184184b756960e7

[Anthony Martin]

Perhaps I'm missing something but is it safe to call ready
outside of the p->rlock?

I thought it was a requirement for a Rendez to be kept
around by other means if there is a possibility that it may
be accessed by other proc. So isn't the Rendez on the stack
in semacquire the actual problem?

If I'm wrong, wouldn't it be easier to reason about if we
used Richard Miller's solution (from the comment above
wakeup)?

The key change is to zero r->p immediately after saving it
to p so the critical section involving r is just:

	lock(r)
	p = r->p
	r->p = nil
	unlock(r)

What do you think?

Cheers,
   Anthony

P.S.
As an aside, I really dislike procinterrupt (a.k.a postnote
or swiproc). The asynchronous nature makes it difficult to
reason about the invariants in sleep and wakeup.

Has anyone experimented with alternative designs?

Re: [9front] Re: commit b3a26fb633f4649fc202b77c0184184b756960e7

[cinap_lenrek]

> Perhaps I'm missing something but is it safe to call ready
> outside of the p->rlock?

I do not see any issue with calling ready() outside
of the p->rlock.

In sleep, we set the process state to Wakeme
only when we have both locks. From there on, we'r
committed to go to sleep and we can call ready()
on it (once).

Double ready should not happen as we clear r->p and p->r.

> I thought it was a requirement for a Rendez to be kept
> around by other means if there is a possibility that it may
> be accessed by other proc.

I do not know of any such requirements. The sleep and
wakeup paper is also silent on this topic and the bug
is also right there in the listed code.

The only requirement i know is that Proc's must never
be re-used as something other than a Proc.

> So isn't the Rendez on the stack in semacquire the actual problem?

I can see this being a issue also if the Rendez or QLock
is in dynamically allocated memory. Not just the stack.

I also dont like the Rendez on the stack and i know
we can even save some memory by just using &up->sleep
as the rendezvous point instead of embedding it the
Sema struct. But this isnt addressing the problem at hand.

> ...

> The key change is to zero r->p immediately after saving it
> to p so the critical section involving r is just:

>	lock(r)
>	p = r->p
>	r->p = nil
>	unlock(r)

Maybe, tho i wanted to address the problem at hand.

> What do you think?

I'm going back to sleep :)

--
cinap

Re: [9front] Re: commit b3a26fb633f4649fc202b77c0184184b756960e7

[cinap_lenrek]

> As an aside, I really dislike procinterrupt (a.k.a postnote
> or swiproc). The asynchronous nature makes it difficult to
> reason about the invariants in sleep and wakeup.

> Has anyone experimented with alternative designs?

yes, i thought about this delivering them as separate
process sharing the same segments, tho it is too late,
i have to sleep. i'll elaborate another time.

tho interrupting one process is still something you
need to support for canceling i/o's. no matter how
you dress it.

9front has a "interrupt" ctl message in proc that only
does the interruption without delivering a note
for that.

--
cinap