this might fix the reported deadlock, though I can't reproduce it.
This commit is contained in:
parent
5bf3fbee00
commit
d63ac118e8
18
proc.c
18
proc.c
|
@ -82,6 +82,12 @@ userinit(void)
|
|||
acquire(&ptable.lock);
|
||||
|
||||
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;
|
||||
if((p->pgdir = setupkvm()) == 0)
|
||||
panic("userinit: out of memory?");
|
||||
|
@ -99,6 +105,12 @@ userinit(void)
|
|||
safestrcpy(p->name, "initcode", sizeof(p->name));
|
||||
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;
|
||||
|
||||
release(&ptable.lock);
|
||||
|
@ -141,6 +153,8 @@ fork(void)
|
|||
return -1;
|
||||
}
|
||||
|
||||
release(&ptable.lock);
|
||||
|
||||
// Copy process state from p.
|
||||
if((np->pgdir = copyuvm(proc->pgdir, proc->sz)) == 0){
|
||||
kfree(np->kstack);
|
||||
|
@ -165,6 +179,8 @@ fork(void)
|
|||
|
||||
pid = np->pid;
|
||||
|
||||
acquire(&ptable.lock);
|
||||
|
||||
np->state = RUNNABLE;
|
||||
|
||||
release(&ptable.lock);
|
||||
|
@ -227,7 +243,7 @@ wait(void)
|
|||
|
||||
acquire(&ptable.lock);
|
||||
for(;;){
|
||||
// Scan through table looking for zombie children.
|
||||
// Scan through table looking for exited children.
|
||||
havekids = 0;
|
||||
for(p = ptable.proc; p < &ptable.proc[NPROC]; p++){
|
||||
if(p->parent != proc)
|
||||
|
|
Loading…
Reference in a new issue