Download Notes on Synchronization - Operating Systems | CMPSCI 377 and more Study notes Operating Systems in PDF only on Docsity!
CMPSCI 377 Operating Systems Fall 2007
Lecture 9: October 18
Lecturer: Emery Berger Scribe: Andrew Huang
9.1 Synchronization
9.1.1 Consistency
Threads must ensure consistency. Otherwise, threads may result in a race condition leading to a non- deterministic result. A race is when the result is dependent the order in which the threads finish.
For example: Thread A says x = 1, and if (x == 2), then print ‘What?’ Thread B says x = 2. What is x?
Threads require synchronization operations for this to be answered.
9.2 ‘The too much milk problem
The too much milk problem
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:30 Arrive home, put milk in fridge 3:35 Arrive at grocery 3:40 Buy milk 3:45 Arrive home, put milk in fridge 3:50 Uh oh!
This is why we need to synchronize activities!
Terminology
Definition 9.1 Mutual exclusion (mutex) prevents multiple threads from entering. The critical sec- tion is code that only one thread can execute at a time. A lock is a mechanism for mutual exclusion.
9-2 Lecture 9: October 18
- Lock on entering critical section, accessing shared data
- Unlock when complete
- Wait if locked
9.2.1 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)
9.2.2 Too Much Milk: Attempt 1
thread A thread B
if(no milk && no note) if (no milk && no note) leave note leave note buy milk buy note remove note remove note
! If both threads switch after reading the if statement, then both will buy milk.
9.2.3 Too Much Milk: Attempt 2
Idea: use labeled notes
thread A thread B
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
9-4 Lecture 9: October 18
Asymmetrical
- Threads A & B are different
- Adding more threads = different code for each thread
Poor utilization
- Busy waiting consumes CPU, no useful work
- time could be better spent on other work
Possibly non-portable
- Relies on atomicity of loads & stores
- atomicity is ”all of nothing”
9.3 Language Support
Synchronization (making an area of code atomic) is complicated Better way - provide language-level support
- Higher-level approach
- Hide gory details in runtime system
Increasingly high-level approaches (pthread supplies all these):
- Locks, Atomic Operations
- Semaphores - generalized locks
- Monitors - tie shared data to synchronization
9.4 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
Lecture 9: October 18 9-
9.4.1 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);
9.4.2 Pthreads API
Routine Prefix Functional Group pthread Threads themselves and miscellaneous subroutines pthread attr Threads attributes objects pthread mutex Mutexes
9.4.3 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 lock(l) p m lock(l)
The code in both threads is exactly the same. Clean, symmetric - but how do we implement it? Hardware support prevents both locks from happening at the same time. Dekker’s algorithm allows mutual exlusion.
9.4.4 Implementing Locks
Requires hardware support (in general) Can build on atomic operations:
- Load/Store
- Disable interrupts
- Uniprocessors only, this does not work on multiprocessors
- Says to OS, ”Shut up, don’t switch me out or interrupt me!”
- Test & Set, Compare & Swap
Lecture 9: October 18 9-
9.4.6 Locks via Disabling Interrupts
9.4.7 Barrier
X = 1
Y = 2
Z = X
Could run Z=x, and then X=1, because reads can come first but..
Barrier prevents misordering X = 1 BARRIER //don’t execute until above is done Y = 2 Z = X
9.5 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)
