this might fix the reported deadlock, though I can't reproduce it.

This commit is contained in:
Robert Morris 2016-09-08 14:22:38 -04:00
parent 5bf3fbee00
commit d63ac118e8

18
proc.c
View file

@ -82,6 +82,12 @@ userinit(void)
acquire(&ptable.lock); acquire(&ptable.lock);
p = allocproc(); p = allocproc();
// release the lock in case namei() sleeps.
// the lock isn't needed because no other
// thread will look at an EMBRYO proc.
release(&ptable.lock);
initproc = p; initproc = p;
if((p->pgdir = setupkvm()) == 0) if((p->pgdir = setupkvm()) == 0)
panic("userinit: out of memory?"); panic("userinit: out of memory?");
@ -99,6 +105,12 @@ userinit(void)
safestrcpy(p->name, "initcode", sizeof(p->name)); safestrcpy(p->name, "initcode", sizeof(p->name));
p->cwd = namei("/"); p->cwd = namei("/");
// this assignment to p->state lets other cores
// run this process. the acquire forces the above
// writes to be visible, and the lock is also needed
// because the assignment might not be atomic.
acquire(&ptable.lock);
p->state = RUNNABLE; p->state = RUNNABLE;
release(&ptable.lock); release(&ptable.lock);
@ -141,6 +153,8 @@ fork(void)
return -1; return -1;
} }
release(&ptable.lock);
// Copy process state from p. // Copy process state from p.
if((np->pgdir = copyuvm(proc->pgdir, proc->sz)) == 0){ if((np->pgdir = copyuvm(proc->pgdir, proc->sz)) == 0){
kfree(np->kstack); kfree(np->kstack);
@ -165,6 +179,8 @@ fork(void)
pid = np->pid; pid = np->pid;
acquire(&ptable.lock);
np->state = RUNNABLE; np->state = RUNNABLE;
release(&ptable.lock); release(&ptable.lock);
@ -227,7 +243,7 @@ wait(void)
acquire(&ptable.lock); acquire(&ptable.lock);
for(;;){ for(;;){
// Scan through table looking for zombie children. // Scan through table looking for exited children.
havekids = 0; havekids = 0;
for(p = ptable.proc; p < &ptable.proc[NPROC]; p++){ for(p = ptable.proc; p < &ptable.proc[NPROC]; p++){
if(p->parent != proc) if(p->parent != proc)