CS 346 – Sect. 5.1-5.

2
• Process synchronization
– What is the problem?
– Criteria for solution
– Producer / consumer example

– General problems difficult because of subtleties

 Problem
• It’s often desirable for processes/threads to share data
– Can be a form of communication
– One may need data being produced by the other
• Concurrent access  possible data inconsistency
• Need to “synchronize”…
– HW or SW techniques to ensure orderly execution
• Bartender & drinker
– Bartender takes empty glass and fills it
– Drinker takes full glass and drinks contents
– What if drinker overeager and starts drinking too soon?
– What if drinker not finished when bartender returns?
– Must ensure we don’t spill on counter.
 Key concepts
• Critical section = code containing access to shared data
– Looking up a value or modifying it
• Race condition = situation where outcome of code
depends on the order in which processes take turns
– The correctness of the code should not depend on scheduling

• Simple example: producer / consumer code, p. 204

– Producer adds data to buffer and executes ++count;
– Consumer grabs data and executes --count;
– Assume count initially 5.
– Let’s see what could happen…
 Machine code
Producer’s ++count becomes:
1 r1 = count
2 r1 = r1 + 1
3 count = r1

Consumer’s --count becomes:

4 r2 = count
5 r2 = r2 – 1
6 count = r2

Does this code work?

Yes, if we execute in order 1,2,3,4,5,6 or 4,5,6,1,2,3 -- see why?
Scheduler may have other ideas!
 Alternate schedules
1 r1 = count 1 r1 = count
2 r1 = r1 + 1 2 r1 = r1 + 1
4 r2 = count 4 r2 = count
5 r2 = r2 – 1 5 r2 = r2 – 1
3 count = r1 6 count = r2
6 count = r2 3 count = r1

• What are the final values of count?

• How could these situations happen?
• If the updating of a single variable is nontrivial, you
can imagine how critical the general problem is!
 Solution criteria
• How do we know we have solved a synchronization
problem? 3 criteria:
• Mutual exclusion – Only 1 process may be inside its
critical section at any one time.
– Note: For simplicity we’re assuming there is one zone of shared
data, so each process using it has 1 critical section.
• Progress – Don’t hesitate to enter your critical section if
no one else is in theirs.
– Avoid an overly conservative solution
• Bounded waiting – There is a limit on # of times you may
access your critical section if another is still waiting to
enter theirs.
– Avoid starvation
 Solution skeleton
while (true)
{
Seek permission to enter critical section
Do critical section
Announce done with critical section
Do non-critical code
}

• BTW, easy solution is to forbid preemption.

– But this power can be abused.
– Identifying critical section  can avoid preemption for a shorter
period of time.
 CS 346 – Sect. 5.3-5.7
• Process synchronization
– A useful example is “producer-consumer” problem
– Peterson’s solution
– HW support
– Semaphores
– “Dining philosophers”

• Commitment
– Compile and run semaphore code from os-book.com
 Peterson’s solution
… to the 2-process producer/consumer problem. (p. 204)
while (true)
{
ready[ me ] = true
turn = other
while (ready[ other ] && turn == other) ;
Do critical section
ready[ me ] = false
Do non-critical code
}

// Don’t memorize but think: Why does this ensure mutual exclusion?
// What assumptions does this solution make?
 HW support
• As we mentioned before, we can disable interrupts
–  No one can preempt me.
– Disadvantages

• The usual way to handle synchronization is by careful

programming (SW)
• We require some atomic HW operations
– A short sequence of assembly instructions guaranteed to be
non-interruptable
– This keeps non-preemption duration to absolute minimum
– Access to “lock” variables visible to all threads
– e.g. swapping the values in 2 variables
– e.g. get and set some value (aka “test and set”)
 Semaphore
• Dijkstra’s solution to mutual exclusion problem
• Semaphore object
– integer value attribute ( > 0 means resource is available)
– acquire and release methods
• Semaphore variants: binary and counting
– Binary semaphore aka “mutex” or “mutex lock”

acquire() release()
{ {
if (value <= 0) ++value
wait/sleep // wake sleeper
--value }
}
 Deadlock / starvation
• After we solve a mutual exclusion problem, also need to
avoid other problems
– Another way of expressing our synchronization goals

• Deadlock: 2+ process waiting for an event that can only

be performed by one of the waiting processes
– the opposite of progress

• Starvation: being blocked for an indefinite or unbounded

amount of time
– e.g. Potentially stuck on a semaphore wait queue forever
 Bounded-buffer problem
• aka “producer-consumer”. See figures 5.9 – 5.10
• Producer class
– run( ) to be executed by a thread
– Periodically call insert( )
• Consumer class
– Also to be run by a thread
– Periodically call remove( )
• BoundedBuffer class
– Creates semaphores (mutex, empty, full): why 3?
Initial values: mutex = 1, empty = SIZE, full = 0
– Implements insert( ) and remove( ).
These methods contain calls to semaphore operations acquire( )
and release( ).
 Insert & delete
public void insert(E item) public E remove()
{ {
empty.acquire(); full.acquire();
mutex.acquire(); mutex.acquire();

// add an item to the // remove item ...

// buffer...

mutex.release();
mutex.release();
empty.release();
full.release();
}
}

• What are we doing with the semaphores?

 Readers/writers problem
• More general than producer-consumer
• We may have multiple readers and writers of shared info
• Mutual exclusion requirement:
Must ensure that writers have exclusive access
• It’s okay to have multiple readers reading

See example solution, Fig. 5.10 – 5.12

• Reader and Writer threads periodically want to execute.
– Operations guarded by semaphore operations
• Database class (analogous to BoundedBuffer earlier)
– readerCount
– 2 semaphores: one to protect database, one to protect the
updating of readerCount
 Solution outline
Reader: Writer:
mutex.acquire(); db.acquire();
++readerCount;
if(readerCount == 1) // WRITE NOW
db.acquire();
mutex.release(); db.release();

// READ NOW

mutex.acquire();
--readerCount;
if(readerCount == 0)
db.release();
mutex.release();
 Example output
writer 0 wants to write.
writer 0 is writing.
writer 0 is done writing.
reader 2 wants to read.
writer 1 wants to write.
reader 0 wants to read.
reader 1 wants to read.
Reader 2 is reading. Reader count = 1
Reader 0 is reading. Reader count = 2
Reader 1 is reading. Reader count = 3
writer 0 wants to write.
Reader 1 is done reading. Reader count = 2
Reader 2 is done reading. Reader count = 1
Reader 0 is done reading. Reader count = 0
writer 1 is writing.
reader 0 wants to read.
writer 1 is done writing.
 CS 346 – Sect. 5.7-5.8
• Process synchronization
– “Dining philosophers” (Dijkstra, 1965)
– Monitors
 Dining philosophers
• Classic OS problem
– Many possible solutions depending on how foolproof you want
solution to be
• Simulates synchronization situation of several resources,
and several potential consumers.
• What is the problem?
• Model chopsticks with semaphores – available or not.
– Initialize each to be 1
• Achieve mutual exclusion:
– acquire left and right chopsticks (numbered i and i+1)
– Eat
– release left and right chopsticks
• What could go wrong?
 DP (2)
• What can we say about this solution?
mutex.acquire();
Acquire 2 neighboring forks
Eat
Release the 2 forks
mutex.release();

• Other improvements:
– Ability to see if either neighbor is eating
– May make more sense to associate semaphore with the
philosophers, not the forks. A philosopher should block if cannot
acquire both forks.
– When done eating, wake up either neighbor if necessary.
 Monitor
• Higher level than semaphore
– Semaphore coding can be buggy
• Programming language construct
– Special kind of class / data type
– Hides implementation detail
• Automatically ensures mutual exclusion
– Only 1 thread may be “inside” monitor at any one time
– Attributes of monitor are the shared variables
– Methods in monitor deal with specific synchronization problem.
This is where you access shared variables.
– Constructor can initialize shared variables
• Supported by a number of HLLs
– Concurrent Pascal, Java, C#
 Condition variables
• With a monitor, you get mutual exclusion
• If you also want to ensure against deadlock or starvation,
you need condition variables
• Special data type associated with monitors
• Declared with other shared attributes of monitor
• How to use them:
– No attribute value to manipulate. 2 functions only:
– Wait: if you call this, you go to sleep. (Enter a queue)
– Signal: means you release a resource, waking up a thread
waiting for it.
– Each condition variable has its own queue of waiting
threads/processes.
 Signal( )
• A subtle issue for signal…
• In a monitor, only 1 thread may be running at a time.
• Suppose P calls x.wait( ). It’s now asleep.
• Later, Q calls x.signal( ) in order to yield resource to
P.
• What should happen? 3 design alternatives:
– “blocking signal” – Q immediately goes to sleep so that P can
continue.
– “nonblocking signal” – P does not actually resume until Q has left
the monitor
– Compromise – Q immediately exits the monitor.
• Whoever gets to continue running may have to go to
sleep on another condition variable.
 CS 346 – Sect. 5.9
• Process synchronization
– “Dining philosophers” monitor solution
– Java synchronization
– atomic operations
 Monitor for DP
• Figure 5.18 on page 228
• Shared variable attributes:
– state for each philosopher
– “self” condition variable for each philosopher
• takeForks( )
– Declare myself hungry
– See if I can get the forks. If not, go to sleep.
• returnForks( )
– Why do we call test( )?
• test( )
– If I’m hungry and my neighbors are not eating, then I will eat and
leave the monitor.
 Synch in Java
• “thread safe” = data remain consistent even if we have
concurrently running threads

• If waiting for a (semaphore) value to become positive

– Busy waiting loop 
– Better: Java provides Thread.yield( ): “block me”

• But even “yielding” ourselves can cause livelock

– Continually attempting an operation that fails
– e.g. You wait for another process to run, but the scheduler
keeps scheduling you instead because you have higher priority
 Synchronized
• Java’s answer to synchronization is the keyword
synchronized – qualifier for method
as in public synchronized void funName(params) { …
• When you call a synchronized method belonging to an
object, you obtain a “lock” on that object
e.g. sem.acquire();
• Lock automatically released when you exit method.
• If you try to call a synchronized method, & the object is
already locked by another thread, you are blocked and
sent to the object’s entry set.
– Not quite a queue. JVM may arbitrarily choose who gets in next
 Avoid deadlock
• Producer/consumer example
– Suppose buffer is full. Producer now running.
– Producer calls insert( ). Successfully enters method  has lock
on the buffer. Because buffer full, calls Thread.yield( ) so that
consumer can eat some data.
– Consumer wakes up, but cannot enter remove( ) method
because producer still has lock.  we have deadlock.
• Solution is to use wait( ) and notify( ).
– When you wait, you release the lock, go to sleep (blocked), and
enter the object’s wait set. Not to be confused with entry set.
– When you notify, JVM picks a thread T from the wait set and
moves it to entry set. T now eligible to run, and continues from
point after its call to wait().
 notifyAll
• Put every waiting thread into the entry set.
– Good idea if you think  > 1 thread waiting.
– Now, all these threads compete for next use of synchronized
object.
• Sometimes, just calling notify can lead to deadlock
– Book’s doWork example ***
– Threads are numbered
– doWork has a shared variable turn. You can only do work here if
it’s your turn: if turn == your number.
– Thread 3 is doing work, sets turn to 4, and then leaves.
– But thread 4 is not in the wait set. All other threads will go to
sleep.
 More Java support
See: java.util.concurrent
• Built-in ReentrantLock class
– Create an object of this class; call its lock and unlock
methods to access your critical section (p. 282)
– Allows you to set priority to waiting threads

• Condition interface (condition variable)

– Meant to be used with a lock. What is the goal?
– await( ) and notify( )

• Semaphore class
– acquire( ) and release( )
 Atomic operations
• Behind the scenes, need to make sure instructions are
performed in appropriate order
• “transaction” = 1 single logical function performed by a
thread
– In this case, involving shared memory
– We want it to run atomically
• As we perform individual instructions, things might go
smoothly or not
– If all ok, then commit
– If not, abort and “roll back” to earlier state of computation
• This is easier if we have fewer instructions in a row to do
 Keeping the order
Transaction 1 Transaction 2 Transaction 1 Transaction 2
Read (A) Read (A)
Write (A) Write (A)
Read (B) Read (A)
Write (B) Write (A)
Read (A) Read (B)
Write (A) Write (B)
Read (B) Read (B)
Write (B) Write (B)

• Are these two schedules equivalent? Why?