stanonik (08/19/82)
Operating systems classes seem to spend a quarter of their time explaining the importance of mutual exclusion and how to achieve it. But, 'locks' in the UNIX kernel don't seem quite right. Below are two fragments from the kernel which ostensibly do some locking, but in fact don't really prevent two processes from getting through because the testing and setting of the lock are not indivisble. /* * Lock a page frame. */ mlock(pf) /*fragment from vmmem.c, version 4.1*/ { while (c->c_lock) sleep((caddr_t)c, PSWP+1); c->c_lock = 1; } /* * sys-trace system call. */ ptrace() /*fragment from iget.c, version 4.1*/ { while (ipc.ip_lock) sleep((caddr_t)&ipc, IPCPRI); ipc.ip_lock = p->p_pid; } What gives? I can think of three explanations. 1) It is unlikely that two processes will be timed just right so that both get through. (Anything possible will happen in time!) 2) Somehow only one process at a time can call this code. (Cryptic!) 3) I'm missing something obvious. (Enlightenment please!) When the kernel does want to guarentee mutual exclusion, it seems to bracket the code with spl6 and splx to turn off and on, respectively, any interrupts which might cause a user level context switch. Ron Stanonik EECS UCSD !ucbvax!sdcsvax!stanonik !sdcsvax!stanonik@nprdc