8: Lecture Synchronization
David Lie
ECE344
University of Toronto
1
Overview
Need for synchronization
Different synchronization primitives
Locks
Conditional Variables
Semaphores
Common Synchronization Problems
Deadlocks, Livelock, starvation
Tradeoffs with implementing synchronization
ECE344: Operating Systems
2
Concurrent Programming
Programming with two or more cooperating threads
Threads can cooperate by
Sharing data (shared address space)
Global and heap variables are shared (not locals)
Using messages (send and receive using bounded buffer)
Can be implemented using shared variables
Generally, more expensive but more robust
ECE344: Operating Systems
3
Concurrent Programming
Issues:
There can be requirements on the ordering of operations
between the threads:
Race Conditions
Two threads T1 and T2 read and update the same variable
Access to the threads must be exclusive (i.e. One at a time)
Synchronization
T1 initializes a variable, T2 runs after variable is initialized
Ordering between T1 and T2 must be enforced
ECE344: Operating Systems
4
Race Conditions
A race condition exists in a program when the result of program
execution depends on the interleaving of operations between
the threads
Definition: A linearizable sequence is a sequence of
operations that has the same result if the operations
happened atomically.
Any sequence that is not linearizable is a race
ECE344: Operating Systems
5
Race Condition Bugs
Data race:
Two threads performs access on a shared variable
simultaneously and at least one performs a write
Note that not all race conditions are bugs. Some race
conditions can also benign. Examples?
ECE344: Operating Systems
6
Common Race Conditions
Atomicity violation:
2 or more operations should not be interrupted but another
thread operates between them in a non-linearizable way.
ECE344: Operating Systems
7
Common Race Conditions
Ordering violation:
There is a ordering constraint on operations between two or
more threads, but this constraint is violated. Example?
ECE344: Operating Systems
8
How Should Race Conditions be Avoided?
Certain interleavings will lead to incorrect results, so we need a
way to prevent these interleavings
Option 1: No interleavings. Disable interrupts and every
thread runs to completion before the next one stops.
Option 2: Coordinate among threads by preventing some
threads from running at certain times. This is called
synchronization.
ECE344: Operating Systems
9
Synchronization
3 types of synchronization primitives:
Mutex Locks
Conditional Variables
Semaphores
ECE344: Operating Systems
10
Critical Sections and Mutual Exclusion
A critical section is a piece of code that needs to execute
atomically
E.g., Read, modify, write is a critical section
Mutual exclusion is a requirement that only one thread access a
critical section at a time
All other threads are forced to wait on entry
When a thread leaves critical section, others can enter
If mutual exclusion can be ensured for every critical section, then
there will be no atomicity violations!
ECE344: Operating Systems
11
Mutual Exclusion Requirements
1. No two threads simultaneously in critical section
2. No thread running outside its critical section may block another
thread
Why is this bad?
3. No thread must wait forever to enter its critical section
Why is this bad?
4. No constraints or assumption on the speed that thread execute
Threads can execute at any rate relative to each other
Thread execution can switch to another thread at any time.
ECE344: Operating Systems
12
Mutex Lock Abstraction
A mutex lock (or simply a lock) is a tool for guaranteeing mutual
exclusion. It has two operations:
lock(mutex)
Acquire the lock if it is free
Otherwise wait (or sleep) until it can be acquired
Lock is now acquired
unlock(mutex)
Release the lock
If there are waiting threads wake up one of them
Lock is now free
ECE344: Operating Systems
13
Using a Mutex Lock
// variables located in shared address space
int i;
struct lock *i_lock;
while() {
lock(i_lock);
// section;
i critical = i + 1;
unlock(i_lock);
// remainder section;
}
while() {
lock(i_lock);
// critical section;
i = i + 1;
unlock(i_lock);
// remainder section;
}
Thread 1
Thread 2
ECE344: Operating Systems
15
Implementing Mutex Locks
Naive implementation:
lock(boolean *l) {
while (*l == TRUE)
; // no-op
*l = TRUE;
}
unlock(boolean *l) {
*l = FALSE;
}
Lock and unlock are critical sections themselves
They access the Mutex shared data structure
In this case, the Mutex is a pointer to a boolean
We are back to the same problem!
Next, we discuss four different solutions
ECE344: Operating Systems
16
Implementation 1: Interrupt Disabling
Use interrupt disabling to lock processor
Once interrupts are disabled, no other thread is able to run, so
thread runs atomically
lock_i() {
disable_interrupts
}
unlock_i() {
enable_interrupts
}
In practice, the implementation of unlock_i() will set the interrupt
level to its value before the call to lock_i()
Suppose interrupts are enabled and lock is called twice
Then two unlocks are needed to enable interrupts
What is the problem with this implementation?
ECE344: Operating Systems
17
Implementation 2: Spin Locks
Problems:
Only for kernel: interrupts cannot be disabled in user mode
On multi-processors, interrupts disabled only on local
processor
No way to disable interrupts across all processors at
once
Prevents all threads from entering critical section, only one
lock
Cant declare different locks for different variables
Need hardware support!
ECE344: Operating Systems
18
Implementation 2: Spin Locks
Hardware provides atomic operations
Various primitives:
Atomic Test, Set and Lock, Compare and Swap, etc
Available to user mode
Atomic instructions can help implement mutex locks
ECE344: Operating Systems
19
Test-and-Set-Lock Instruction
Tset instruction operates on an integer with two values
0 = FALSE = not locked
1 = TRUE = locked
int tset(int *lock) { // atomic in hardware
int old = *lock;
*lock = TRUE;
return old;
}
Semantics
If returned value is FALSE, lock is acquired
If returned value is TRUE, some one else has lock
So try again later
ECE344: Operating Systems
20
Using test and set
lock_s(int *l) {
while (tset(l))
; // no-op
}
unlock_s(int *l) {
*l = FALSE;
}
Threads wait in a tight loop, keeping processor busy
This kind of mutex lock is called a spin lock
How can we improve this implementation?
ECE344: Operating Systems
21
Implementation 3: Yielding Locks
Previous solution: busy waiting, polling or spinning
Threads consume processor cycles to detect when the lock has
become free!
On a single processor system, this time is completely
wasted. Why?
How about blocking a thread instead of busy waiting
One option is to use the thread_yield() call
Yield voluntarily gives up current time slice
At user level, requires yield() system call
ECE344: Operating Systems
22
Implementing Yielding Locks
lock_s(int *l) {
while (tset(l))
thread_yield();
}
unlock_s(int *l) {
*l = FALSE;
}
This mutex is a yielding lock
It is no longer busy waiting
Are there any problems with this solution?
ECE344: Operating Systems
23
Implementation 4: Blocking Locks
Previous solution is not spinning, but it is still polling
Even better would just have the thread_sleep until the lock is
free
When lock is released, call thread_wake on all threads
sleeping on the lock
These primitives access shared lists:
thread_wakeup() removes from sleep list and adds element
to ready list
thread_sleep() adds to sleep list
They must be performed in a critical section
Requires locking while we are trying to implement a lock!
How should this problem be solved?
ECE344: Operating Systems
24
Using a Previous Solution
Solution 1 or 2 work correctly but dont block
Use them to access the shared ready list
For uniprocessors
Disable interrupts inside thread_sleep and thread_wakeup
For multi-processors
Use spin locks inside thread_sleep and thread_wakeup
OS161 Lab 1 requires you to implement blocking locks
ECE344: Operating Systems
25