From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4C075676.4010504@bouyapop.org> Date: Thu, 3 Jun 2010 09:15:02 +0200 From: Philippe Anel 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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [9fans] run queues Topicbox-Message-UUID: 2ee7849a-ead6-11e9-9d60-3106f5b1d025 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 ? >> > > >