Emery Berger

1
Operating SystemsCMPSCI 377Lecture 7
Synchronization

• Emery Berger
• University of Massachusetts, Amherst

2
Last Time Scheduling Algorithms

• FCFS
• First-Come, First-Served
• Round-robin
• Use quantum preemption to alternate jobs
• SJF
• Shortest job first
• Multilevel Feedback Queues
• Round robin on each priority queue
• Lottery Scheduling
• Jobs get tickets
• Scheduler randomly picks winner

3
This Time Synchronization

• Threads must communicate to ensure consistency
• Else race condition (non-deterministic result)
• Synchronization operations
• How to write concurrent code
• How to implement synch. operations

4
Synchronization Motivation

• The too much milk problem
• Model of need to synchronize activities

5
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

6
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)
• Dont buy milk if theres a note (wait)

7
Too Much Milk Solution 1

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

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

• too much milk

• Does this work?

8
Too Much Milk Solution 2
Idea use labeled notes

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

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

• oops no milk

9
Too Much Milk Solution 3
Idea wait for the right note

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

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

• Must try all possibilities to verify

10
Too Much Milk Solution 3
Possibility 1 A first, then B

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

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

• OK

11
Too Much Milk Solution 3
Possibility 2 B first, then A

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

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

• OK

12
Too Much Milk Solution 3
Possibility 3 Interleaved A waits buys

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

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

• OK

13
Too Much Milk Solution 3
Possibility 4 Interleaved A waits, B buys

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

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

• OK

14
Too Much Milk Solution 3

• Solution 3Thread A waits for B, otherwise
  buys
• Correct preserves desired properties
• Safety we only buy one milk
• Progress we always buy milk
• But

15
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 resources, no useful
  work
• Possibly non-portable
• Relies on atomicity of loads stores

16
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

17
Locks

• Provide mutual exclusion to shared data via two
  atomic routines
• LockAcquire wait for lock, then take it
• LockRelease unlock, wake up waiters
• Rules
• Acquire lock before accessing shared data
• Release lock afterwards
• Lock initially released

18
Too Much Milk Locks
thread A Lock.acquire() if (no milk) buy
milk Lock.release()
thread B Lock.acquire() if (no milk) buy
milk Lock.release()

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

19
Implementing Locks

• Requires hardware support (in general)
• Can build on atomic operations
• Load/Store
• Disable interrupts
• Uniprocessors only
• Test Set, Compare Swap

20
Disabling Interrupts

• Prevent scheduler from switching threads in
  middle of critical sections
• Ignores quantum expiration (timer interrupt)
• No handling I/O operations
• (Dont make I/O calls in critical section!)
• Why not implement as system call?

21
Implementing LocksDisabling Interrupts

• Class Lock
• private int value
• private Queue q
• Lock ()
• value 0 q empty
• public void acquire ()
• disable interrupts
• if (value BUSY)
• add this thread to q
• sleep()
• else
• value BUSY
• enable interrupts

public void release () disable
interrupts if (q not empty) thread t
q.pop() put t on ready queue else
value FREE enable
interrupts
22
ExampleLocks via Disabling Interrupts
23
Summary

• Communication between threadsvia 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)

24
Next Time

• More synchronization
• Semaphores
• Monitors