From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <4C14EA90.8020108@bouyapop.org>
Date: Sun, 13 Jun 2010 16:26:24 +0200
From: Philippe Anel <xigh@bouyapop.org>
User-Agent: Thunderbird 2.0.0.24 (X11/20100318)
MIME-Version: 1.0
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
References: <8ebe5bdc32ec6d9b7efc27b0b0b3697c@hamnavoe.com>
In-Reply-To: <8ebe5bdc32ec6d9b7efc27b0b0b3697c@hamnavoe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] 9vx, kproc and *double sleep*
Topicbox-Message-UUID: 322fcf4a-ead6-11e9-9d60-3106f5b1d025

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