From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: [sources] 20070413: /rc/bin/cpurc.local
From: "Russ Cox" <rsc@swtch.com>
Date: Sun, 15 Apr 2007 13:59:19 -0400
In-Reply-To: <9ab217670704151043j1da7acc2j61869c6d54f736f7@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20070415175854.B53311E8C26@holo.morphisms.net>
Topicbox-Message-UUID: 491463dc-ead2-11e9-9d60-3106f5b1d025

>> p->mach is a pointer back to a machine structure. I'm assuming this
>> only gets set when a process is being run. I suppose this test is here
>> in case another CPU took over running the process.
> 
> Though, this can't be the case, because m->readied isn't locked when
> we come in here, and if we're running MP, wouldn't it be possible
> (though unlikely) that another CPU takes the process between the
> assignment and the test? Especially if running heavily threaded
> applications on MP systems?

	/* cooperative scheduling until the clock ticks */
	if((p=m->readied) && p->mach==0 && p->state==Ready
	&& runq[Nrq-1].head == nil && runq[Nrq-2].head == nil){

The tests are:

	p=m->readied
		some process p was last readied on this cpu (Mach)
	
	p->mach == 0
		p is not running on any cpu right now
	
	p->state == Ready
		p is still Ready (waiting to run)
	
	runq[Nrq-1].head == nil && runq[Nrq-2].head == nil
		there are no real-time processes waiting to run

If all those succeed, then the code tries to choose
p to run next.  But it might not -- the next thing that 
happens is

	p = dequeueproc(rq, p);

which can return nil if p has already been grabbed
or even if there is contention for the runq lock.
All the accesses in the if condition are just fine --
they happen without a lock but dequeueproc double-checks
that p is okay to schedule.

If dequeueproc returns nil, then runproc won't pick 
the readied p after all -- it will fall into the regular
scheduling loop to find a process.

Russ