1. Atomicity, Mutex, and Locks
David Ferry CSCI 3500 – Operating Systems
Saint Louis University St. Louis, MO 63103

2. CSCI 3500 - Operating Systems
Critical Sections
Recall the problem with race conditions: Suppose x=0 initially: Thread 1 Thread 2 u = x v = x u = u + 1 v = v * 2 x = u x = v A critical section is any piece of code that should not execute simultaneously with another piece of code.
CSCI Operating Systems

3. CSCI 3500 - Operating Systems
Critical Sections
Recall the problem with race conditions: Suppose x=0 initially: Thread 1 Thread 2 u = x v = x u = u + 1 v = v * 2 x = u x = v A critical section is any piece of code that should not execute simultaneously with another piece of code (potentially itself- see push() from last time).
CSCI Operating Systems

4. Locks & Mutex (Mutual Exclusion)
We need to prevent simultaneous access to critical sections. Something like:
mutex m;
lock(m);
//Do critical section
unlock(m);
Where lock(m):
Proceeds if m is unlocked
If not, blocks until m is unlocked
CSCI Operating Systems

5. Implementing lock() and unlock()?
lock() should block until the mutex variable is unlocked, a naïve implementation: int mutex = 0; lock( mutex ): unlock( mutex ): while(1){ mutex = 0; if( mutex == 0 ){ mutex = 1; break; }
CSCI Operating Systems

6. CSCI 3500 - Operating Systems
But wait…
Another race condition! lock( mutex ) translates to: while(1){ start: if( mutex == 0 ){ load m to register mutex = 1; compare m break; jump if not zero->start } store 1 to memory } What if we could simultaneously test and update the value of the mutex variable?
CSCI Operating Systems

7. CSCI 3500 - Operating Systems
Atomic Operations
An atomic operation is one that is indivisible.
From the previous slide, what we want is this:
if ( m == 0 ) //Test the value of m
m = 1; //Set the value of m
If this were atomic, then it looks as though both statements execute simultaneously.
The outside world sees the “before” or “after” but never any intermediate states.
In particular, a second thread can’t come along and read the value of m after it has already been read but before the assignment m=1 takes place.
CSCI Operating Systems

8. CSCI 3500 - Operating Systems
Hardware to the Rescue
Hardware designers can give us a special atomic test and set instruction. Then: lock(mutex): while(1){ int success = hardware_test_and_set(mutex); if( success ) break; } The lock() functions we use probably look something like this, modulo performance optimizations.
CSCI Operating Systems

9. CSCI 3500 - Operating Systems
Unsatisfying?
Do we have to rely on hardware giving us a special “solve everything” instruction? In fact, mutual exclusion can be accomplished only with regular memory loads and stores (i.e. in software). The first such solution, Dekker’s Algorithm, was published by Edsger Dijkstra in Leslie Lamport published the first general solution called the Bakery Algorithm in Other solutions exist since then. Hardware implementations tend to be faster and easier to implement. However, software-only solutions can be useful, such as when portability is important.
CSCI Operating Systems

10. Other Atomic Operations
We will see other atomic operations in the studios. E.g.: __sync_fetch_and_add(); This function synchronously (atomically) loads a value from memory and adds to it. Thread 1: Thread 2: x++; x++;
CSCI Operating Systems

11. Solving Race Conditions
Critical sections occur when variables are shared between threads, in particular when shared variables are written to.
lock() and unlock():
Can encapsulate any critical section
Code/data can be any size
Atomic operations:
Usually faster, if applicable
CSCI Operating Systems