Operating Systems - Synchronization

Operating Systems
CMPSCI 377
Synchronization
Emery Berger
University of Massachusetts Amherst

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science

Synchronization

Threads must ensure consistency


Else: race condition


(non-deterministic result)
Requires synchronization operations


How to write concurrent code


How to implement synch. operations


UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 2

Synchronization – Motivation
“The too much milk problem”


Model of need to synchronize activities



Synchronization Terminology

Mutual exclusion (“mutex”)
– prevents multiple threads from entering
Critical section
– code only one thread can execute at a time
Lock
– mechanism for mutual exclusion
Lock on entering critical section, accessing shared


data
Unlock when complete


Wait if locked



Solving the Too Much Milk Problem
Correctness properties


Only one person buys milk


 Safety: “nothing bad happens”

Someone buys milk if you need to


 Progress: “something good eventually happens”

First: use atomic loads & stores as building blocks


“Leave a note” (lock)


“Remove a note” (unlock)


“Don’t buy milk if there’s a note” (wait)



Too Much Milk: Solution 1

thread B
thread A
if (no milk && no note) if (no milk && no note)
leave note leave note
buy milk buy milk
remove note remove note

Does this work?much milk
too




Idea: use labeled notes

thread B
thread A
leave note A leave note B
if (no note B) if (no note A)
if (no milk) if (no milk)
buy milk buy milk
remove note A remove note B

oops – no milk



Idea: wait for the right note

thread B
thread A
while (note B) if (no note A)
do nothing if (no milk)
if (no milk) buy milk
buy milk remove note B
remove note A

Exercise: verify this



Possibility 1: A first, then B

thread B
thread A
remove note A

OK



Possibility 2: B first, then A

thread B
thread A
remove note A

OK



Possibility 3: Interleaved – A waits & buys

thread B
thread A
remove note A

OK



Possibility 4: Interleaved – A waits, B buys

thread B
thread A
remove note A

OK


Solution 3:
“Thread A waits for B, otherwise buys”

Correct – preserves desired properties


Safety: we only buy one milk


Progress: we always buy milk


But…



Problems with this Solution
Complicated


Difficult to convince ourselves that it works


Asymmetrical


Threads A & B are different


Adding more threads = different code for each thread


Poor utilization


Busy waiting – consumes CPU, no useful work


Possibly non-portable


Relies on atomicity of loads & stores



Language Support
Synchronization complicated


Better way – provide language-level

support
Higher-level approach


Hide gory details in runtime system


Increasingly high-level approaches:


Locks, Atomic Operations


Semaphores – generalized locks


Monitors – tie shared data to

synchronization

Locks
Provide mutual exclusion to shared data

via two atomic routines
acquire – wait for lock, then take it


release – unlock, wake up waiters


Rules:


Acquire lock before accessing shared data


Release lock afterwards


Lock initially released



Pthreads Syntax
POSIX standard for C/C++


Mutual exclusion locks


Ensures only one thread in critical section


pthread_mutex_init (&l);
…

pthread_mutex_lock (&l);
update data; /* critical section */
pthread_mutex_unlock (&l);


Pthreads API


Too Much Milk: Locks

thread A thread B
p_m_lock(&l) p_m_lock(&l)
if (no milk) if (no milk)
buy milk buy milk
p_m_unlock(&l) p_m_unlock(&l)

Clean, symmetric - but how do we implement it?


Implementing Locks
Requires hardware support (in general)


Can build on atomic operations:


Load/Store


Disable interrupts


Uniprocessors only


Test & Set, Compare & Swap



Disabling Interrupts
Prevent scheduler from switching threads


in middle of critical sections
Ignores quantum expiration (timer interrupt)


No handling I/O operations


(Don’t make I/O calls in critical section!)


Why not implement as system call?



Disabling Interrupts
Class Lock {
private int value;
private Queue q;

Lock () {
value = 0; q = empty;
}

public void release () {
public void acquire () {
disable interrupts;
disable interrupts;
if (q not empty) {
if (value == BUSY) {
thread t = q.pop();
add this thread to q;
put t on ready queue;
enable interrupts;
}
sleep();
value = FREE;
} else {
enable interrupts;
value = BUSY;
}
}
enable interrupts;
}


Locks via Disabling Interrupts


Summary

Communication between threads:


via shared variables
Critical sections = regions of code that


modify or access shared variables
Must be protected by synchronization


primitives that ensure mutual exclusion
Loads & stores: tricky, error-prone


Solution: high-level primitives (e.g., locks)



The End


Operating Systems - Synchronization

Related slideshows

More Related Content

Operating Systems - Synchronization