From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <9ae7a59b9cd1c0742a8f6920615fd98c@plan9.bell-labs.com>
To: 9fans@9fans.net
Cc: 9fans@9fans.net
Date: Thu,  3 Jun 2010 10:12:02 +0200
From: Sape Mullender <sape@plan9.bell-labs.com>
In-Reply-To: <4C075676.4010504@bouyapop.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] run queues
Topicbox-Message-UUID: 2ef0440e-ead6-11e9-9d60-3106f5b1d025

Yes, that's right.

	Sape


> From: xigh@bouyapop.org
> To: 9fans@9fans.net
> Reply-To: 9fans@9fans.net
> Date: Thu Jun  3 09:15:42 CES 2010
> Subject: Re: [9fans] run queues
>
>
> Thank you. That's what I was thinking. I suppose this has been written
> like this because traversing the queue might require too much time for
> having a lock.
>
> Phil;
>
> Sape Mullender wrote:
> > Well spotted. But the queue is maintained in a way that
> > traversing it while it's being changed cannot cause one
> > to address garbage (rnext always contains a pointer to a
> > proc or nil) and, at the label found, the sanity check
> > is performed to see if we really have a proc on the queue
> > in our hands. Worst case is that the search terminates too
> > early, but then we just stay in the search loop.
> >
> > 	Sape
> >
> >
> >
> >> While reading /sys/src/9/port/proc.c:^runproc, I realized that the
> >> following code is called without any lock. I would expect one in order
> >> to walk through the each rq lists, as it is called with interrupt
> >> enabled.
> >>
> >> I think this would not crash the system because procs are not
> >> dynamically allocated or freed.
> >>
> >> I also know that locking can be a problem regarding performance.
> >>
> >> for(rq = &runq[Nrq-1]; rq >= runq; rq--){
> >> for(p = rq->head; p; p = p->rnext){
> >> if(p->mp == nil || p->mp == MACHP(m->machno)
> >> || (!p->wired && i > 0))
> >> goto found;
> >> }
> >> }
> >>
> >> What do you think ?
> >>
> >
> >
> >
>