1. Synchronization Methods
CS 105 “Tour of the Black Holes of Computing”
Synchronization Methods
Topics
Mutual-exclusion methods
Producer/consumer problem
Readers/writers problem
Class10_synchronization

2. Deadlock and Starvation
Three bad things can happen in concurrency
Inconsistency: incorrect results, e.g. from races
Deadlock: Nobody can make progress
Starvation: No deadlock, but somebody doesn’t make progress

3. Mutual Exclusion Need ways to enforce critical sections
Prevent race conditions that cause errors
Requirements for mutual exclusion
Safety: only one process or 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 doesn’t waste resources
Fairness: if you want in, nobody else gets in ahead of you twice

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

5. 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; if match then store some other register into word
Again, indivisible
Generalization of Test & Set
Double Compare and Swap
Extends CAS to two (noncontiguous) locations
Turns out to not be that useful; omitted in current designs

6. Example of Test and Set enter_critical_region: leaq 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:
movb $0, lock

7. Evaluating Test and Set
Very fast entry to unlocked region
Easy to implement (except on multi-core hardware!)
Guarantees safety & progress
Wastes CPU when waiting (spin lock/busy wait)
Doesn’t 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 unfairness and starvation
For these reasons, test & set is used only to implement higher-level constructs

8. 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
P’s and V’s must be matched
Single extra V blows mutual exclusion entirely (compare Test & Set)

9. Monitors High-level mutual-exclusion construct
Invented by C.A.R. “Tony” Hoare (also quicksort inventor)
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
Charles Anthony Richard Hoare, 1980 Turing Award winner

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

11. 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
Order must be maintained
Solutions
Can be done with just load/store (but tricky)
We have seen simple semaphore-based solution for one-element buffer
Perfect application for monitors

12. Producer/Consumer with Monitors
monitor producerconsumermonitor;
var buffer[0..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);
buffer[nexttofill] := data;
nexttofill := (nexttofill + 1) mod slots;
slotsinuse := slotsinuse + 1;
signal(bufferhasdata);
end;
Note that this wait/signal model is very similar to what the Posix thread model provides, although Posix doesn't provide the encapsulation.

13. Producer/Consumer with Monitors (continued)
procedure emptyslot(var data: message) begin
if slotsinuse = 0;
then wait(bufferhasdata);
data := buffer[nexttoempty];
nexttoempty = (nexttoempty + 1) mod slots;
slotsinuse := slotsinuse – 1;
signal(bufferhasspace);
end;
begin
slotsinuse := 0;
nexttofill := 0;
nexttoempty := 0;

14. Exercise: P/C with Semaphores
Form a small team (2-4 people)
Sketch out a producer/consumer solution
Multiple slots in buffer
Buffer used circularly (“ring” buffer)
Use only two semaphores
Find a way to count with them!

15. Solution: P/C with Semaphores
semaphore empty_slots = N;
semaphore full_slots = 0;
void produce(int data) {
P(empty_slots);
buffer[next_empty] = data;
next_empty = (next_empty + 1) % N;
V(full_slots); }
int consume()
P(full_slots);
data = buffer[next_full];
next_full = (next_full + 1) % N;
V(empty_slots);
return data;

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

17. 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(); }
nreaders++;
read();
nreaders--;
Note that since you're polling, this is very close to using Test and Set. Also, this version suffers from starvation (while you’re in “wait_a_while” somebody else can grab the write lock). It’s also unfair in that a late-arriving writer can keep out an earlier reader, and vice versa. It has neither reader nor writer priority.

18. Readers/Writers with Semaphores (Polling continued)
void writer() {
while (1) {
P(mutex);
while (nreaders + nwriters != 0) {
V(mutex);
wait_a_while(); }
nwriters++;
V(mutex); /* not really needed – why? */
write();
P(mutex); /* not really needed */
nwriters--;

19. Readers/Writers with Semaphores (Polling continued)
What are the drawbacks of this approach?
How can we write a non-polling version?
Drawbacks: (1) the polling wastes resources; (2) potential starvation of writers if new readers arrive while a writer is waiting

20. 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);

21. 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);
begin
readers := 0;

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

23. 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” doesn’t work (why?)
Solvable with semaphores or monitors

24. Drinking Philosophers
Extension of dining philosophers, due to K.M. Chandy
Arbitrary number of philosophers
Each likes own drink, mixed from bottles on table
Can only mix drink when holding all necessary bottles
Each drink uses different subset of bottles
Problem: control access to bottles, such that there is no deadlock and no starvation
Solution uses Dining Philosophers as sub-problem.