Chapter 5
Concurrency: Mutual Exclusion and Synchronization

The Two-Much-Milk Problem

What kind of knowledge and mechanisms do we need to get independent processes to communicate and get a consistent view of the world (computer state)?

Example: Too-Much-Milk

Time	You	Your Roommate
3:00	Arrive Home
3:05	Look in fridge; no milk
3:10	Leave for grocery
3:15		Arrive home
3:20	Arrive at grocery	Look in fridge; no milk
3:25	Buy milk	Leave for grocery
3:35	Arrive home; put milk in fridge
3:45		Buy milk
3:50		Arrive home; oh no!

Synchronization Terminology

Synchronization: Using atomic actions to ensure cooperation between threads.

Mutual Exclusion: Ensuring that only one thread does a particular activity at a time. One thread doing that activity excludes all the others from doing the same thing at that time.

Critical Section: A piece of code that can be executed by only one thread at a time.

Lock: Prevents other threads from doing something. The thread that performs the Lock operation is said to acquire the lock and to be the owner of it.

A thread should acquire the lock before entering its critical section.
A thread should release the lock (perform an Unlock operation) when leaving its critical section.
Unlocks should (normally) be performed only by the owners of the lock.
Only one thread can be the owner of a lock.
A thread must wait if it is unable to acquire a lock.

Solving the Too-Much-Milk Problem

Correctness Properties: We want to ensure the following.

Only one person buys milk at a time (mutual exclusion).
Someone always buys milk if it is needed (progress).

We will restrict ourselves to atomic loads and stores as building blocks:

Leave a note (set a flag) -- a version of Lock.
Remove a note (reset a flag) -- a version of Unlock.
Do not buy milk if there is a note (test the flag).

Solution 1

Thread A

if (noMilk & noNote)
leave Note;
buy milk;
remove Note;

Thread B

if (noMilk & noNote)
leave Note;
buy milk;
remove Note;

Does this work? No, you may wind up with two milks.

Solution 2

Thread A:

leave noteA;
if (no noteB)
   if (noMilk) buy milk;
remove NoteA;

Thread B:

leave noteB;
if (no noteA)
   if (noMilk) buy milk;
remove NoteB;

Does this work? No, you may wind up with no milk.

Solution 3

Thread A:

leave noteA;
while (noteB) do nothing;
if (noMilk) buy milk;
remove NoteA;

Thread B:

leave noteB;
if (no noteA)
if (noMilk) buy milk;
remove NoteB;

Does this work? Yes.

Is Solution 3 a good solution? No.

It is too complicated.
It is asymmetrical. Threads A and B have different code. Adding new threads would require different code for the new threads as well as modifications to the existing code.
Thread A is busy waiting, consuming CPU cycles without accomplishing any useful work.

How do we get a simple, symmetrical solution that does not involve busy waiting?

A Solution Using Locks

One way is by using locks. There are two atomic operations on locks:

Lock::Acquire --wait until lock is free, then claim it.
Lock::Release -- unlock, and wake up some thread that is waiting to acquire the lock (if there are any waiting).

Our solution requires only that:

The lock is always acquired before accessing shared data.
The lock is always released after finishing with shared data.
No two threads can hold the lock at the same time.
The lock is initially free.

Solution 4

Thread A:

Lock->Acquire();
if (noMilk) buy milk;
Lock->Release();

Thread B:

Lock->Acquire();
if (noMilk) buy milk;
Lock->Release();

Two questions:

How do we make Release and Acquire atomic?
How do we make sure our implementation avoids busy waiting?

Implementing Locks

How do we make Acquire and Release atomic? There are two ways that a thread can lose control of the CPU:

Internal events: The thread does something, like I/O, to relinquish control. The thread can prevent this by not requesting any I/O operations during a critical section.
External events: Interrupts cause the scheduler to take control away from the running thread. These are impossible for a thread to control unless either
- Threads are allowed to disable interrupts. Not a good idea in general, or
- There is some atomic instruction supplied in hardware that can be used, or
- The thread gets some help from the O/S.

Implementing locks in hardware

Most uniprocessor architectures supply an atomic read-modify-write instruction that is easily implemented in hardware. Some examples:

Test&Set: Read a value from a memory location; write 1 back to that location. (most architectures)

int Test&Set(int value) { // all done atomically!
   int temp;
   temp = value;
   value = 1;
   return temp;
}

Exchange: Swap values between a register and a memory location. (x86)
Compare&Swap: Read a value from a memory location; if the value matches register value r1, then exchange values between register r2 and the memory location. (68000)
Load Linked and Conditional Store: Read a value in one instruction; do an operation; when a store occurs, check to see if the value has been modified. If not, do the store. If it has changed, abort the store and jump back to the read. (R4000, Dec Alpha)

Example: Implementing locks with Test&Set

class Lock {
   public:
      Lock();
      void Acquire();
      void Release();
   private:
      int value;
}

Lock::Lock() {
   value = 0;
}

Lock::Acquire() {
   while (Test&Set(value) == 1) ; // busy wait until the lock is free
}

Lock::Release() {
   value = 0;
}

What's wrong with this solution?

The acquiring thread is busy waiting. How can we get the waiting thread to give up the CPU so the releasing thread can execute?
What happens with threads of different priorities?

A better implementation

With Test&Set, we can't get rid of the busy waiting, but we can minimize it by busy waiting only to check the lock value. If the lock is busy, the the thread gives up the CPU. To do so, we need to provide routines to put threads to sleep and wake them up:

Thread::Sleep() {
   remove thread from ready queue;
   add thread to waiting queue;
}

Wakeup(Thread T) {
   remove T from waiting queue;
   add T to ready queue;
}

Now we can implement Locks efficiently:

class Lock {
   public:
      Lock();
      void Acquire();
      void Release();
   private:
      int value;
      int guard;
}

Lock::Lock() {
   value = FREE;
   guard = 0;
}

Lock::Acquire(Thread T) {
   while (Test&Set(guard) == 1) ; // busy wait
   if (value != FREE) {
      put T on queue Q;
      T->Sleep();
      guard = 0; // The O/S must do this after T has gone to sleep
   }
   else {
      value = BUSY;
      guard = 0;
   }
}

Lock::Release() {
   while (Test&Set(guard) == 1) ; // busy wait
   if Q is not empty {
      choose a thread T from Q;
      Wakeup(T);
   }
   else
      value = FREE;
}

Software Implementations of Locks

We can get rid of busy waiting entirely by having the O/S implement locks in software:

class Lock {
public:
Lock();
void Acquire(T: Thread);
void Release();
private:
int value;
Queue Q;
}

Lock::Lock() {
// lock is free
value = 0;
// queue is empty
Q = nil;
}

Lock::Acquire(T: Thread) {
   disable interrupts;
   if (value == 1) {
      add T to queue Q;
      T->Sleep();
   }
   else {
      value = 1;
      enable interrupts;
   }
}

Lock::Release() {
   disable interrupts;
   if (Q is not empty) {
      remove a thread T from Q;
      Wakeup(T);
   }
   else {
      value = 0;
   }
   enable interrupts;
}

Question: When does Acquire enable interrupts?

Would it be safe to enable interrupts before adding the thread T to the queue? No, Release might check the queue before T is added to the queue. T would not get waked up.

Would it be safe to enable interrupts after putting the thread on the queue but before the thread goes to sleep? No, Release might put T back on the ready queue before T goes to sleep. In that case, when T wakes up, it will go right back to sleep, effectively missing the wakeup call.

But if the thread is already asleep, then how can it enable interrupts? It can't; some other thread must do that for it. In Nachos, Thread::Sleep() disables interrupts, but it is the responsibility of the next thread that executes to enable interrupts.

Condition Variables

Now that we have locks and can implement critical sections safely, one problem still remains: Sometimes a thread needs to go to sleep while inside its critical section (while waiting for something to be put into a buffer, for example), but if it holds onto the lock while it sleeps, then other threads will not be able to wake it up. Condition variables solve this problem by atomically releasing the lock when the thread is put to sleep.

A condition variable is a queue of threads waiting inside a critical section. Condition variables support three operations:

Wait (Lock lock) -- atomically release the lock and go to sleep.
Signal() -- Wake up a waiting thread if one exists; otherwise do nothing.
Broadcast() -- Wake up all waiting threads.

Rules for using condition variables:

Each condition variable is associated with a lock.
Several condition variables may be associated with the lock.
A thread must hold the lock when doing operations on a condition variable.

Example: A Bounded Queue

class Queue {
   public:
      Queue();
      void AddToQueue(ItemType);
      ItemType RemoveFromQueue();
   private:
      Lock lock;
      Condition notEmpty;
      Condition notFull;
      ...                // queue data structures
}

Queue::Queue() {
    initialize an empty queue;
}

void Queue::AddToQueue(ItemType item) {
   lock->Acquire();
   while (queue is full)
      notFull->Wait(lock);
   put item in queue;
   notEmpty->Signal();
   lock->Release();
}

ItemType Queue::RemoveFromQueue() {
   lock->Acquire();
   while (queue is empty)
      notEmpty->Wait(lock);
   remove item from queue;
   notFull->Signal();
   lock->Release();
   return item;
}

Semantics of Condition Variables

What happens when a thread issues a signal on a condition variable? There are two popular answers:

Hoare semantics -- also called signal-and-wait. The signalling thread S is immediately blocked and one thread waiting on that condition variable is awakened. The lock is transferred immediately from S to the newly awakened thread T. When T releases the lock, it is immediately reacquired by the original signalling thread S. This is the semantics found in most operating systems textbooks.
Hoare semantics guarantee that whatever condition T was waiting for will still hold true when T resumes processing, assuming that the condition involves data structures protected by the lock and that it is true when S signals. Since T immediately gets the lock, no other thread, including S, can access the data structures before T does:
```
if (conditions the thread needs are not true) condition->Wait();
```
Mesa semantics -- also called signal-and-continue, notify-and-continue, or Lampson-Redell semantics. When the signal is issued by S, one thread T waiting on that condition is awakened and put on the queue of threads waiting to acquire the lock. However, S keeps the lock. When S releases the lock, some thread that is waiting on the lock acquires it, but this is not necessarily T. This is the semantics used in Nachos and most operating systems.
Because T may not be the next thread to access the protected data structure, Mesa semantics can not guarantee that whatever condition T was waiting for will still hold true when T regains the lock. Hence when T reacquires the lock, it must test again and wait on the condition again if necessary:
```
while (conditions the thread needs are not true) condition->wait();
```
Monitors
Condition variables first arose in the context of a monitor, a high-level synchronization construct defined by Hoare in 1974. A monitor is similar to a C++ class that ties the data, operations and, in particular, the synchronizations all together. Here is a monitor version of our queue example, using Hoare semantics, with Pascal-like syntax to emphasize how monitors are different from classes defined in terms of locks and condition variables:
```
monitor queue;
      not_empty, not_full: Condition;
      ...                // queue data structures

procedure add(item_type item);
begin
   if (queue is full) then wait(not_full);
   put item in queue;
   signal(not_empty)
end;

function remove: item_type;
item: item_type;
begin
   if (queue is empty) then wait(not_empty);
   remove item from queue;
   remove := item
   signal(not_full);
end;

begin
   initialize empty queue data structures
end;
```
Note that, in Pascal style, this defines a single monitor, not a class of monitors.
Where are the locks? They are part of the underlying implementation. A thread wanting to access the queue must call one of the queue procedures (this is called entering the monitor). Only one thread at a time is allowed to be actively executing a monitor procedure; all other threads that are in the monitor must be sleeping. The underlying implementation takes care of ensuring this.

Chapter 5 Concurrency: Mutual Exclusion and Synchronization

The Two-Much-Milk Problem

Synchronization Terminology

Solving the Too-Much-Milk Problem

A Solution Using Locks

Implementing Locks

Software Implementations of Locks

Condition Variables

Chapter 5
Concurrency: Mutual Exclusion and Synchronization