This document discusses synchronization in operating systems and concurrent programming. It introduces the concept of critical sections and mutual exclusion locks that allow only one thread to access shared data at a time. It presents solutions to the "too much milk" problem using notes and waiting to ensure only one thread buys milk at a time. The document then discusses implementing locks using disabling interrupts as well as higher-level synchronization primitives like semaphores and monitors that make concurrent programming easier.

1. Operating Systems
CMPSCI 377
Synchronization
Emery Berger
University of Massachusetts Amherst
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science

2. 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

3. Synchronization – Motivation
“The too much milk problem”

Model of need to synchronize activities

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 3

4. 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

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 4

5. 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)

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 5

6. 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

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 6

7. Too Much Milk: Solution 2
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
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 7

8. Too Much Milk: Solution 3
Idea: wait for the right note
thread B
thread A
leave note A leave note B
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

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 8

9. Too Much Milk: Solution 3
Possibility 1: A first, then B
thread B
thread A
leave note A leave note B
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
OK

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 9

10. Too Much Milk: Solution 3
Possibility 2: B first, then A
thread B
thread A
leave note A leave note B
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
OK

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 10

11. Too Much Milk: Solution 3
Possibility 3: Interleaved – A waits & buys
thread B
thread A
leave note A leave note B
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
OK

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 11

12. Too Much Milk: Solution 3
Possibility 4: Interleaved – A waits, B buys
thread B
thread A
leave note A leave note B
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
OK

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 12

13. Too Much Milk: Solution 3
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…

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 13

14. 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

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 14

15. 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
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 15

16. 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

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 16

17. 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);
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 17

18. Pthreads API
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 18

19. 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?

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 19

20. Implementing Locks
Requires hardware support (in general)

Can build on atomic operations:

Load/Store

Disable interrupts

Uniprocessors only

Test & Set, Compare & Swap

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 20

21. 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?

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 21

22. 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;
}
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 22

23. Locks via Disabling Interrupts
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 23

24. 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)

UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 24

25. The End
UNIVERSITY OF MASSACHUSETTS AMHERST • Department of Computer Science 25