In fact you're right, and this shows us this would only happens to 9vx.
Indeed, the proc is a kproc and thus is not scheduled by the
9vx/a/proc.c scheduler,
but by the one in 9vx/sched.c ... where dequeueproc() is not called and
where p->mach
is not checked.
Thank you !
Phil;
Richard Miller wrote:
Philippe said:
Again, the change I proposed is not about sleep/wakeup/postnote, but
because wakeup() is ready()'ing the awakened process while the mach on
which sleep() runs is still holdind a pointer (up) to the awakened
process and can later (in schedinit()) assumes it is safe to access
(up)->state. Because of this, schedinit() can tries to call ready() on
(up), because because (up)->state may have been changed to Running by
a third mach entity.
and I tried to summarize:
It's a race between a process in sleep() returning to the scheduler on
cpu A, and the same process being readied and rescheduled on cpu B
after the wakeup.
But after further study of proc.c, I now believe we were both wrong.
A process on the ready queue can only be taken off the queue and
scheduled by calling dequeueproc(), which contains this:
/*
* p->mach==0 only when process state is saved
*/
if(p == 0 || p->mach){
unlock(runq);
return nil;
}
So the process p can only be scheduled (i.e. p->state set to Running)
if p->mach==nil.
The only place p->mach gets set to nil is in schedinit(), *after*
the test for p->state==Running.
This seems to mean there isn't a race after all, and Philippe's
thought experiment is impossible.
Am I missing something?
