Operating Systems
Topic: Concurrency – Locks
Endadul Hoque
Acknowledgement
• Youjip Won (Hanyang University)
• OSTEP book – by Remzi and Andrea Arpaci-Dusseau
(University of Wisconsin)
Locks: The basic idea
• Ensure that any critical section executes as if it were a
single atomic instruction.
– An example: the canonical update of a shared variable
balance = balance + 1;
– Add some code around the critical section
1 lock_t mutex; // some globally-allocated lock ‘mutex’
2 ...
3 lock(&mutex);
4 balance = balance + 1;
5 unlock(&mutex);
Locks: The basic idea
• Lock variable holds the state of the lock.
– available (or unlocked or free)
• No thread holds the lock.
– acquired (or locked or held)
• Exactly one thread holds the lock and presumably is in a
critical section.
The semantics of the lock()
• lock()
– Try to acquire the lock.
– If no other thread holds the lock, the thread will
acquire the lock.
– Enter the critical section.
• This thread is said to be the owner of the lock.
– Other threads are prevented from entering the critical
section while the first thread that holds the lock is in
there.
Pthread Locks - mutex
• The name that the POSIX library uses for a lock.
– Used to provide mutual exclusion between threads.
1 pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
2
3 Pthread_mutex_lock(&lock); // wrapper for pthread_mutex_lock()
4 balance = balance + 1;
5 Pthread_mutex_unlock(&lock);
– Instead of using one big lock (a coarse-grained approach), we
may be using different locks to protect different variables (a more
fine-grained approach) → Increase concurrency.
Building A Lock
• Efficient locks must provide mutual
exclusion at low cost.
• Building a lock needs some help from the
hardware and the OS.
Evaluating locks – Basic criteria
• Correctness (aka Mutual exclusion)
– Does the lock work, preventing multiple threads from entering a
critical section?
• Fairness
– Does each thread contending for the lock get a fair shot at
acquiring it once it is free? (Addressing starvation)
• Performance
– The time overheads added by using the lock
• Cases: (a) No contention, (b) contention on single CPU, (c) contention on
multiple CPUs
Naïve solution: Controlling Interrupts
• Disable Interrupts for critical sections
– One of the earliest solutions used to provide mutual exclusion
– Invented for single-processor systems.
1 void lock() {
2 DisableInterrupts();
3 }
4 void unlock() {
5 EnableInterrupts();
6 }
Naïve solution: Controlling Interrupts
• Disable Interrupts for critical sections
– One of the earliest solutions used to provide mutual exclusion
– Invented for single-processor systems.
1 void lock() {
2 DisableInterrupts();
3 }
4 void unlock() {
5 EnableInterrupts();
• Problems:
6 }
– Require too much trust in applications
• Greedy (or malicious) program could monopolize the processor.
– Do not work on multiprocessors
– Disabling interrupts for a longer time can lose important interrupts
– Code that masks or unmasks interrupts be executed slowly by modern
CPUs
Why is hardware support needed?
• First attempt: Using a flag denoting whether the lock is
held or not.
– The code below has problems.
1 typedef struct __lock_t { int flag; } lock_t;
2
3 void init(lock_t *mutex) {
4 // 0 → lock is available, 1 → held
5 mutex->flag = 0;
6 }
7
8 void lock(lock_t *mutex) {
9 while (mutex->flag == 1) // TEST the flag
10 ; // spin-wait (do nothing)
11 mutex->flag = 1; // now SET it !
12 }
13
14 void unlock(lock_t *mutex) {
15 mutex->flag = 0;
16 }
Why is hardware support needed?
– Problem 1: No Mutual Exclusion
Thread1 Thread2
Assume
call lock()
flag=0 while (flag == 1)
interrupt: switch to Thread 2
call lock()
while (flag == 1)
flag = 1;
interrupt: switch to Thread 1
flag = 1; // set flag to 1 (too!)
– Problem 2: Spin-waiting wastes time waiting for another thread.
• So, we need an atomic instruction supported by Hardware!
– E.g., test-and-set instruction, also known as atomic exchange
Test And Set (Atomic Exchange)
• An H/W instruction to support the creation of simple
locks
• This instruction operates as follows (C pseudocode):
1 int TestAndSet(int *ptr, int new) {
2 int old = *ptr; // fetch old value at ptr
3 *ptr = new; // store ‘new’ into ptr
4 return old; // return the old value
5 }
– return old value pointed to by the ptr (testing)
– Simultaneously update said value to new (setting)
– This sequence of operations is performed atomically.
A Simple Spin Lock using test-and-set
1 typedef struct __lock_t {
2 int flag;
3 } lock_t;
4
5 void init(lock_t *lock) {
6 // 0 indicates that lock is available,
7 // 1 that it is held
8 lock->flag = 0;
9 }
10
11 void lock(lock_t *lock) {
12 while (TestAndSet(&lock->flag, 1) == 1)
13 ; // spin-wait
14 }
15
16 void unlock(lock_t *lock) {
17 lock->flag = 0;
18 }
Note: To work correctly on a single processor,
it requires a preemptive scheduler.
Evaluating Spin Locks (using Test-and-
Set)
• Correctness: yes
– The spin lock only allows a single thread to entry the critical section.
• Fairness: no
– Spin locks don’t provide any fairness guarantees.
– Indeed, a thread spinning may spin forever.
• Performance:
– In the single CPU, performance overheads can be quite substantial.
– If the number of threads roughly equals the number of CPUs, spin
locks work reasonably well.
Some other H/W instructions for Spin
Locks
• Compare-and-Swap
• Load-Linked and Store-Conditional
• Fetch-And-Add
If interested to learn more on this, read sections 28.9, 28.10, 28.11
from the book chapter
So Much Spinning
• Hardware-based spin locks are simple and they
work.
• In some cases, these solutions can be quite
inefficient.
– Any time a thread gets caught spinning, it wastes an
entire time slice doing nothing but checking a value.
How To Avoid Spinning?
We’ll need OS Support too!
A Simple Approach: Just Yield
• When you are going to spin, give up the CPU to another thread.
– OS system call moves the caller from the running state to the ready state.
– The cost of a context switch can be substantial and the starvation
problem still exists.
1 void init() {
2 flag = 0;
3 }
4
5 void lock() {
6 while (TestAndSet(&flag, 1) == 1)
7 yield(); // give up the CPU
8 }
9
10 void unlock() {
11 flag = 0;
12 }
Lock with Test-and-set and Yield
Using Queues: Sleeping Instead of
Spinning
• Queue to keep track of which threads are waiting to
acquire the lock.
• park()
– Put a calling thread to sleep
• unpark(threadID)
– Wake up a particular thread as designated by threadID.
Using Queues: Sleeping Instead of
Spinning
1 typedef struct __lock_t { int flag; int guard; queue_t *q; } lock_t;
2
3 void lock_init(lock_t *m) {
4 m->flag = 0;
5 m->guard = 0;
6 queue_init(m->q);
7 }
8
9 void lock(lock_t *m) {
10 while (TestAndSet(&m->guard, 1) == 1)
11 ; // acquire guard lock by spinning (another lock, used internally)
12 if (m->flag == 0) {
13 m->flag = 1; // acquire lock m
14 m->guard = 0; // release guard lock
15 } else {
16 queue_add(m->q, gettid()); // lock m is not available,so queue myself
17 m->guard = 0; // release guard lock
18 park(); // let me sleep
19 }
20 }
21 …
Lock With Queues, Test-and-set, Yield, And Wakeup
Using Queues: Sleeping Instead of
Spinning
22 void unlock(lock_t *m) {
23 while (TestAndSet(&m->guard, 1) == 1)
124 typedef struct __lock_t
; // acquire { int
guard flag;
lock int guard; queue_t *q; } lock_t;
by spinning
225 if (queue_empty(m->q))
326 void lock_init(lock_t *m)let
m->flag = 0; // { go of lock; no one wants it
427 m->flag
else = 0;
528 m->guard = 0;
unpark(queue_remove(m->q)); // wake up a thread, hold lock for it
629 queue_init(m->q);
m->guard = 0;
730 }}
8
9 void lock(lock_t *m) {
10 while (TestAndSet(&m->guard, 1) == 1)
11 ; // acquire guard lock by spinning (another lock, used internally)
12 if (m->flag == 0) {
13 m->flag = 1; // acquire lock m
14 m->guard = 0; // release guard lock
15 } else {
16 queue_add(m->q, gettid()); // lock m is not available,so queue myself
17 m->guard = 0; // release guard lock
18 park(); // let me sleep
19 }
20 }
21 …
Lock With Queues, Test-and-set, Yield, And Wakeup
Wakeup/waiting race
• Scenario:
1. Thread A holds the lock
2. Thread B attempts to acquire lock, hence ends up adding itself
to the queue; but before it could call park(), context switch
happens
3. Thread A releases the lock and calls unpark(), but no thread to
wake up
4. Thread B regains the CPU and calls park() now; thus Thread B
goes to sleep (and potentially sleeps forever).
Wakeup/waiting race
• 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 happens to be interrupted and another thread calls unpark
before park is actually called, the subsequent park returns
immediately instead of sleeping.
1 queue_add(m->q, gettid());
2 setpark(); // new code
3 m->guard = 0;
4 park();
Code modification inside of lock()
Futex
• Linux provides a futex (is similar to Solaris’s park
and unpark), part of nptl library
– futex_wait(address, expected)
• Put the calling thread to sleep
• If the value at address is not equal to expected, the call
returns immediately.
– futex_wake(address)
• Wake one thread that is waiting on the queue.
Reading Material
• Chapter 28 of OSTEP book – by Remzi and Andrea
Arpaci-Dusseau (University of Wisconsin)
http://pages.cs.wisc.edu/~remzi/OSTEP/threads-
locks.pdf
Questions?
