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