The Need For Locking

The need for locking is simple and a lot has been written about it. We will use a pratical example of a race condition often seen in an operating system environment. We will take an example from fork.c in Linux, it is a small and good example.

down_write(&oldmm->mmap_sem);
retval = dup_mmap(mm);
up_write(&oldmm->mmap_sem);

The fork system call in Linux and other Unix variants does the following





Figure 1: The fork() system call

Now consider what could happen if we did not lock the address space of the parent using down_write(&oldmm->mmap_sem), the address space (see figure 1) of the parent could change and what we set out to do i.e, Ensure that parent and child have the same address space at the end of fork, would never be accomplished. The dup_mmap(mm) function duplicates the address space. The deletion of a single page could affect the system call if proper locking is not used. We call the data and code protected by the locks as critical section. In our case the data used by dup_mmap(mm) that is mm is our critical section.

A fundamental assumption of locking is - once we get the lock it is ok for us to go ahead and modify/use the data protected by the lock.

NOTE: Most of the new hardware and software developments demand more concurrency, as we head towards concurrency at various levels of hardware and software, the need for locking and sound locking design principles become more accute.