21

Locks: OS Support

Hardware support got us pretty far: working locks, and even

(as with the case of the ticket lock) fairness in lock acquisition.
However, we still have a problem: what to do when a context
switch occurs in a critical section, and threads start to spin end-
lessly, waiting for the interrupt (lock-holding) thread to be run
again?
To

21.1 A Simple Approach: Just Yield, Baby

Our first try is a simple and friendly approach: when you are
going to spin, instead give up the CPU to another thread. Or, as
Al Davis might say, just yield, baby [D91]. Figure 21.1 presents
the approach.
In this approach, we assume an operating system primitive
yield() which a thread can call when it wants to give up the
CPU and let another thread run. Because a thread can be in one
of three states (running, ready, or blocked), you can think of this
as an OS system call that moves the caller from the running state
to the ready state, and thus promotes another thread to running.
Think about the example with two threads on one CPU; in
this case, our yield-based approach works quite well. If a thread
happens to call lock() and find a lock held, it will simply yield

1
2 L OCKS : OS S UPPORT

void init() {
flag = 0;
}

void lock() {
while (TestAndSet(&flag, 1) == 1)
yield(); // give up the CPU
}

void unlock() {
flag = 0;
}

Figure 21.1: Lock with test-and-set and yield

the CPU, and thus the other thread will run and finish its critical
section. In this simple case, the yielding approach works well.
Let us now consider the case where there are many threads
(say 100) contending for a lock repeatedly. In this case, if one
thread acquires the lock and is preempted before releasing it,
the other 99 will each call lock(), find the lock held, and yield the
CPU. Assuming some kind of round-robin scheduler, each of
the 99 will execute this run-and-yield pattern before the thread
holding the lock gets to run again. While better than our spin-
ning approach (which would waste 99 time slices spinning), this
approach is still costly; the cost of a context switch can be sub-
stantial, and there is thus plenty of waste.
Worse, we have not tackled the starvation problem at all.
A thread may get caught in an endless yield loop while other
threads repeatedly enter and exit the critical section. We clearly
will need an approach that addresses this problem directly.

21.2 Using Queues: Sleeping Instead Of Spinning

The real problem with our previous approaches is that they
leave too much to chance. The scheduler determines which
thread runs next; if the scheduler makes a bad choice, a thread
runs that must either spin waiting for the lock (our first ap-

O PERATING
S YSTEMS A RPACI -D USSEAU
L OCKS : OS S UPPORT 3

proach), or yield the CPU immediately (our second approach).

Either way, there is potential for waste and no prevention of
starvation.
Thus, we must explicitly exert some control over who gets to
acquire the lock next after the current holder releases it. To do
this, we will need a little more OS support, as well as a queue to
keep track of which threads are waiting to enter the lock.
For simplicity, we will use the support provided by Solaris,
in terms of two calls: park() to put a calling thread to sleep,
and unpark(threadID) to wake a particular thread as desig-
nated by threadID. These two routines can be used in tandem
to build a lock that puts a caller to sleep if it tries to acquire
a held lock and wakes it when the lock is free. Let’s look at
the code in Figure 21.2 to understand one possible use of such
primitives.
We do a couple of interesting things in this example. First, we
combine the old test-and-set idea with an explicit queue of lock
waiters to make a more efficient lock. Second, we use a queue to
help control who gets the lock next and thus avoid starvation.
(probably could include some example interleavings here)
You might notice how the guard is used, basically as a spin-
lock around the flag and queue manipulations the lock is us-
ing. This approach thus doesn’t avoid spin-waiting entirely; a
thread might be interrupt while acquiring or releasing the lock,
and thus cause other threads to spin-wait for this one to run
again. However, the time spent spinning is quite limited (just a
few instructions inside the lock and unlock code, instead of the
user-defined critical section), and thus this approach may be a
reasonable one.
Second, you might notice that in lock(), when a thread can
not acquire the lock (it is already held), we are careful to add
ourselves to a queue (by calling the gettid() call to get the
thread ID of the current thread), set guard to 0, and yield the
CPU. A question for the reader: What would happen if the re-
lease of the guard lock came after the park(), and not before?
Hint: something bad.
You might also notice the interesting fact that the flag does

W HAT
A RPACI -D USSEAU H APPENS
W HEN
4 L OCKS : OS S UPPORT

typedef struct __lock_t {

int flag;
int guard;
queue_t *q;
} lock_t;

void lock_init(lock_t *m) {

m->flag = 0;
m->guard = 0;
queue_init(m->q);
}

void lock(lock_t *m) {

while (TestAndSet(&m->guard, 1) == 1)
; //acquire guard lock by spinning
if (m->flag == 0) {
m->flag = 1; // lock is acquired
m->guard = 0;
} else {
queue_add(m->q, gettid());
m->guard = 0;
park();
}
}

void unlock(lock_t *m) {

while (TestAndSet(&m->guard, 1) == 1)
; //acquire guard lock by spinning
if (queue_empty(m->q))
m->flag = 0; // let go of lock; no one wants it
else
unpark(queue_remove(m->q)); // hold lock (for next thread!)
m->guard = 0;
}

Figure 21.2: Lock with Queues, test-and-set, yield, and wakeup

not get set back to 0 when when another thread gets woken up.
Why is this? Well, it is not an error, but rather a necessity! When
a thread is woken up, it will be as if it is returning from park();
however, it does not hold the guard at that point in the code and
thus cannot even try to set the flag to 1. Thus, we just pass the
lock directly from the thread releasing the lock to the next thread

O PERATING
S YSTEMS A RPACI -D USSEAU
 L OCKS : OS S UPPORT 5

acquiring it; flag is not set to 0 in-between.

Finally, you might notice the perceived race condition in the
solution, just before the call to park(). With just the wrong tim-
ing, a thread will be about to park, assuming that it should sleep
until the lock is no longer held. A switch at that time to another
thread (say, a thread holding the lock) could lead to trouble, for
example, if that thread then released the lock. The subsequent
park by the first thread would then sleep forever (potentially).
This problem is sometimes called the wakeup/waiting race; to
avoid it, we need to do some extra work.
Solaris solves this problem by adding a third system call:
setpark(). By calling this routine, a thread can indicate it
is about to park. If it then happens to be interrupted and an-
other thread calls unpark before park is actually called, the sub-
sequent park returns immediately instead of sleeping. The code
modification, inside of lock(), is quite small:

queue_add(m->q, gettid());
setpark(); // new code
m->guard = 0;

A different solution could pass the guard into the kernel. In

that case, the kernel could take precautions to atomically release
the lock and dequeue the running thread.

21.3 Different OS, Different Support

We have thus far seen one type of support that an OS can
provide in order to build a more efficient lock in a thread library.
Other OS’s provide similar support, but sometimes the details
vary.
For example, Linux provides something called a futex which
is similar to the Solaris interface but provides a bit more in-
kernel functionality. Specifically, each futex has associated with
it a specific physical memory location; associated with each such
memory location is an in-kernel queue. Callers can use futex

W HAT
A RPACI -D USSEAU H APPENS
W HEN
6 L OCKS : OS S UPPORT

calls (described below) to sleep and wake as need be on the fu-

tex.
Specifically, two calls are available. The call futex wait(address,
expected) puts the calling thread to sleep, assuming the value
at address is equal to expected. If it is not equal, the call
returns immediately. The call futex wake(address) wakes
one thread that is waiting on the queue. The usage of these in
Linux is as found in 21.3.
void mutex_lock (int *mutex) {
unsigned int v;
/* Bit 31 was clear, we got the mutex (this is the fastpath) */
if (atomic_bit_test_set (mutex, 31) == 0)
return;
atomic_increment (mutex);
while (1) {
if (atomic_bit_test_set (mutex, 31) == 0) {
atomic_decrement (mutex);
return;
}

/* We have to wait now. First make sure the futex value we are
monitoring is truly negative (i.e. locked). */
v = *mutex;
if (v >= 0)
continue;
futex_wait (mutex, v);
}
}

void mutex_unlock (int *mutex) {

/* Adding 0x80000000 to the counter results in 0 if and only if
there are not other interested threads */
if (atomic_add_zero (mutex, 0x80000000))
return;

/* There are other threads waiting for this mutex, wake one of them up.
futex_wake (mutex);

Figure 21.3: Linux-based Futex Locks

This code snippet from lowlevellock.h in the nptl library

in the gnu libc library [L09] is pretty interesting. Basically, it

O PERATING
S YSTEMS A RPACI -D USSEAU
 L OCKS : OS S UPPORT 7

uses a single integer to track both whether the lock is held or

not (the high bit of the integer) and the number of waiters on
the lock (all the other bits). Thus, if the lock is negative, it is
held (because the high bit is set and that bit determines the sign
of the integer). The code is also interesting because it shows how
to optimize for the common case where there is no contention:
with only one thread acquiring and releasing a lock, very little
work is done (the atomic bit test-and-set to lock and an atomic
add to release the lock). See if you can puzzle through the rest
of this “real-world” lock to see how it works.

21.4 Summary
The above approach shows how real locks are built these
days: some hardware support (in the form of a more power-
ful instruction) plus some operating system support (e.g., in the
form of park() and unpark() primitives). Of course, the de-
tails differ, and the exact code to perform such locking is usually
highly tuned. Check out the Solaris or Linux open source code
bases if you want to see more details; they are a fascinating read
[L09, S09].

W HAT
A RPACI -D USSEAU H APPENS
W HEN
8 L OCKS : OS S UPPORT

References
[D91] “Just Win, Baby: Al Davis and His Raiders”
Glenn Dickey, Harcourt 1991
There is even an undoubtedly bad book about Al Davis and his famous “just win” quote.
Or, I guess, the book is more about Al Davis and the Raiders, and maybe not just the quote.
Read the book to find out?

[L09] “glibc 2.9 (include Linux pthreads implementation)”

Available: http://ftp.gnu.org/gnu/glibc/
In particular, take a look at the nptl subdirectory where you will find most of the pthread
support in Linux today.

[S09] “OpenSolaris Thread Library”

Available: http://src.opensolaris.org/source/xref/onnv/onnv-gate/
usr/src/lib/libc/port/threads/synch.c
This is also pretty interesting to look at. Thanks to Mike Swift for the pointer to the code.

O PERATING
S YSTEMS A RPACI -D USSEAU