Synchronization Methods

1
Synchronization Methods
CS 105Tour of the Black Holes of Computing

• Topics
• Mutual-exclusion methods
• Producer/consumer problem
• Readers/writers problem

semaphores.ppt
2
Mutual Exclusion

• Need ways to enforce critical sections
• Prevent race conditions that cause errors
• Requirements for mutual exclusion
• Safety only one process/thread at a time inside
  CS
• Progress if nobody has access and somebody wants
  in, somebody gets in
• No starvation if you want in, you will
  eventually get in
• Desirable properties
• Efficiency can get into CS in relatively few
  instructions
• Low load waiting for CS doesnt waste resources
• Fairness if you want in, nobody else gets in
  ahead of you twice

3
Additional Requirements

• Synchronization is tricky to get right
• Failure to protect critical sections
• Incorrect use of primitives
• Deadlock
• Programmer-friendliness is big plus

4
Hardware Mutex Support

• Test and Set
• Read word, set it nonzero, and set condition
  codes
• All in one indivisible operation
• Compare and Swap
• Read word, compare to register, store other
  register into word
• Again, indivisible
• Generalization of Test Set

5
Example of Test and Set

• enter_critical_region
• leal lock, eax
• .L1 tsl (eax) Set lock NZ, set CC
• jne .L1 Loop if was already NZ
• We now have exclusive access
• ret
• leave_critical_region
• xor eax, eax
• movl eax, lock
• ret

6
Evaluating Test and Set

• Very fast entry to unlocked region
• Easy to implement
• Guarantees safety progress
• Wastes CPU when waiting (spin lock/busy wait)
• Doesnt make it easy for other threads to run
• Extremely high memory (i.e., bus) traffic
• Prone to errors (e.g., forget to unlock)
• Prone to starvation
• For these reasons, test set is used only to
  implement higher-level constructs.

7
Semaphores

• Higher-level construct, discussed previously
• Invented by Edsger Dijkstra
• P(sem) or wait(sem) decrements and possibly waits
• V(sem) or signal(sem) increments and lets
  somebody else in
• Usually implemented by operating system
• Allows scheduler to run different thread while
  waiting
• OS can guarantee fairness and no starvation
• Or can even enforce priority scheme
• More flexibility for user (e.g., can count
  things)
• Still error-prone
• Ps and Vs must be matched
• Single extra V blows mutual exclusion entirely
  (compare Test Set)

8
Monitors

• High-level mutual-exclusion construct
• Invented by C.A.R. Tony Hoare
• Difficult or impossible to use incorrectly
• Like Java/C class combines data with functions
  needed to manage it
• Keys to monitor correctness
• Data is available only to functions within
  monitor
• Specific functions (gatekeepers) control access
• Only one process/thread allowed inside monitor at
  a time
• Queues keep track of who is waiting for monitor
• Turns out to be hard to do certain things with
  monitors
• Programmers wind up standing on heads or
  implementing things like semaphores

9
Problems in Synchronization

• Many standard problems in concurrent programming
• Producer/consumer
• Readers/writers
• Dining philosophers
• Drinking philosophers
• Etc.
• Standard problems capture common situations
• Also give way to evaluate proposed
  synchronization mechanisms

10
The Producer/Consumer Problem

• Two processes communicate
• Producer generates things (e.g., messages) into a
  buffer
• Consumer takes those things and uses them
• Correctness requirements
• Producer must wait if buffer is full
• Consumer must not extract things from empty
  buffer
• Solutions
• Can be done with just load/store (but tricky)
• We have seen simple semaphore-based solution
• Perfect application for monitors

11
Producer/Consumer with Monitors

• monitor producerconsumermonitor
• var buffer0..slots-1 of message
• slotsinuse 0..slots
• nexttofill, nexttoempty 0..slots-1
• bufferhasdata, bufferhasspace condition
• procedure fillslot(var data message) begin
• if slotsinuse slots
• then wait(bufferhasspace)
• buffernexttofill data
• nexttofill (nexttofill 1) mod slots
• slotsinuse slotsinuse 1
• signal(bufferhasdata)
• end

12
Producer/Consumer with Monitors (continued)

• procedure emptyslot(var data message) begin
• if slotsinuse 0
• then wait(bufferhasdata)
• data buffernexttoempty
• nexttoempty (nexttoempty 1) mod slots
• slotsinuse slotsinuse 1
• signal(bufferhasspace)
• end
• begin
• slotsinuse 0
• nexttofill 0
• nexttoempty 0
• end

13
The Readers/Writers Problem

• More complex than producer/consumer
• Many processes accessing single resource
• Some read, some write (some could do both)
• OK for many to read at once
• No danger of stepping on each others feet
• Only one writer allowed at a time
• Examples
• Shared access to file
• ATMs displaying or updating bank balance

14
Readers/Writers with Semaphores (Polling Version)

• semaphore mutex 1
• int nreaders 0, nwriters 0
• void reader()
• while (1)
• P(mutex)
• while (nwriters ! 0)
• V(mutex)
• wait_a_while()
• P(mutex)
• nreaders
• V(mutex)
• read()
• P(mutex)
• nreaders--
• V(mutex)

15
Readers/Writers with Semaphores (Polling
continued)

• void writer()
• while (1)
• P(mutex)
• while (nreaders nwriters ! 0)
• V(mutex)
• wait_a_while()
• P(mutex)
• nwriters
• V(mutex)
• write()
• P(mutex)
• nwriters--
• V(mutex)

16
Readers/Writers with Semaphores (Polling
continued)

• What are the drawbacks of this approach?
• How can we write a non-polling version?

17
Readers/Writers with Monitors

• monitor readersandwriters
• var readers integer
• someonewriting boolean
• readallowed, writeallowed condition
• procedure beginreading begin
• if someonewriting or queue(writeallowed)
• then wait(readallowed)
• readers readers 1
• signal(readallowed)
• end
• procedure donereading begin
• readers readers 1
• if readers 0 then signal(writeallowed)
• end

18
Readers/Writers with Monitors (continued)

• procedure beginwriting begin
• if readers 0 or someonewriting
• then wait(writeallowed)
• someonewriting true
• end
• procedure donewriting begin
• someonewriting false
• if queue(readallowed)
• then signal(readallowed)
• else signal(writeallowed)
• end
• begin
• readers 0
• someonewriting false
• end

19
Readers/Writers with Monitors

• Characteristics of solution
• No starvation
• Arriving readers wait if writer is waiting
• Group of readers runs after each writer
• Arrival order of writer, writer, reader runs in
  different order
• Requires several auxiliary variables

20
Dining Philosophers

• Models many important synchronization problems
• Most famous concurrency problem
• Posed by Dijkstra
• Characteristics
• Five philosophers alternate thinking and eating
• Only food is spaghetti
• Requires two forks
• Each philosopher has assigned seat at round table
• One fork between each pair of plates
• Problem control access to forks, such that
  everyone can eat
• Note that pick up left, then pick up right
  doesnt work
• Solvable with semaphores or monitors

21
Drinking Philosophers

• Extension of dining philosophers
• Arbitrary number of philosophers
• Each likes own drink, mixed from bottles on table
• Can only mix drink when holding all bottles
• Each drink uses different subset of bottles
• Problem control access to bottles, such that
  there is no deadlock and no starvation