From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <8ebe5bdc32ec6d9b7efc27b0b0b3697c@hamnavoe.com>
To: 9fans@9fans.net
From: Richard Miller <9fans@hamnavoe.com>
Date: Sun, 13 Jun 2010 14:01:38 +0100
In-Reply-To: <4C13311B.4050704@bouyapop.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] 9vx, kproc and *double sleep*
Topicbox-Message-UUID: 32187278-ead6-11e9-9d60-3106f5b1d025

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?