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.
Unraveling Multimodality with Large Language Models.pdf
Operating Systems - Synchronization
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