We next examine a more complicated structure, the linked list. Let's start with a basic approach
once again. For simplicity, we will omit some of the obvious routines that such a list would have
and just focus on concurrent insert; we will leave it to the reader to think about lookup, delete, and
so forth. Figure 29.7 shows the code for this rudimentary data structure.
As you can see in the code, the code simply acquires a lock in the insert routine upon entry, and
releases it upon exit. One small tricky issue arises if malloc() happens to fail (a rare case); in this
case, the code must aldo release the lock before failing the insert.
This kind of exceptional control flow has been shown to be quite error prone; a recent study of
Linux kernel patches found that a huge fraction of bugs (nearly 40%) are found on such rarely-
taken code paths (indeed, this obversation sparked some of our own research, in which we
removed all memory-failing paths from a Linux file system, resulting in a more robust system).
Thus, a challenge: can we rewrite the insert and lookup routines to remain correct under
concurrent insert but avoid the case where the failure path also requires us to add the call to
unlock ?
The answer, in this case, is yes. Specifically, we can rearrange the code a bit so that the lock and
release only surround the actual critical section in the insert code, and that a common exit
path is used in the lookup code. The former works because part of the lookup actually need not
be locked; assuming that malloc() itself is thread-safe, each thread can call into it without
worry of race conditions or other concurrency bugs. Only when updating the shared list does
a lock need to be held.