Chapter 6: Process Synchronization

1
Chapter 6 Process Synchronization
2
Chapter 6 Process Synchronization

• Background ? atomic operation
• The Critical-Section Problem
• Petersons Solution
• Synchronization Hardware
• Semaphores
• Classic Problems of Synchronization
• Monitors

3
Background

• Concurrent access to shared data may result in
  data inconsistency
• Maintaining data consistency requires mechanisms
  to ensure the orderly execution of cooperating
  processes
• Suppose that we wanted to provide a solution to
  the consumer-producer problem that fills all the
  buffers.
• We can do so by having an integer counter that
  keeps track of the number of items in the buffer.
  
• Initially, counter is set to 0.
• It is incremented by the producer after it
  produces a new item.
• It is decremented by the consumer after it
  consumes a item.

4
Shared data among producer and consumer
define BUFFER_SIZE 10 typedef struct
int content item item
bufferBUFFER_SIZE int in 0 // initial
state int out 0 // empty int counter 0
5
Producer

• while (TRUE)
• // produce an item and put in nextProduced
• while (counter BUFFER_SIZE) // is buffer
  full?
• // do nothing
• buffer in nextProduced
• in (in 1) BUFFER_SIZE
• counter

6
Consumer

• while (TRUE)
• while (counter 0) // is buffer empty?
• // do nothing
• nextConsumed bufferout
• out (out 1) BUFFER_SIZE
• counter --
• // consume the item in nextConsumed

7
Race Condition

• Although the producer and consumer routines are
  correct separately, they may not function
  correctly when executed concurrently.
• Suppose
• that the value of the variable counter is
  currently 5 and
• that the producer and consumer execute the
  statements counter and counter--
  concurrently.
• Following the execution of these two statements,
  the value of the variable counter may be 4, 5,
  or 6.
• Why?

8
Race Condition

• count could be implemented as register1
  counter register1 register1 1
  counter register1
• count-- could be implemented as register2
  counter register2 register2 - 1
  counter register2
• Consider this execution interleaving with count
  5 initially
• S0 producer execute register1
  counter register1 5S1 producer execute
  register1 register1 1 register1 6 S2
  consumer execute register2 counter register2
  5 S3 consumer execute register2 register2
  - 1 register2 4 S4 producer execute
  counter register1 counter 6 S5
  consumer execute counter register2 counter
  4
• counter 4

9
counter is not ATOMIC
S - Box

• E - Box

2. operand
1. data
3. execution
4. result
Ex. --------------------------- E-bo
x S-box --------------------------- CPU
Memory Computer Disk -------------------------
---
Separation of Execution Box Storage Box
10
Race Conditioncounter, counter-- are not ATOMIC
Producer E - Box
Consumer E - Box
S - Box
counter--
counter
counter
11
Example of a Race Condition
CPU1
CPU2
P1
P2
Memory
X 2
X X 1
X X 1
Load X, R1 Inc R1 Store X, R1
Load X, R2 Dec R2 Store X, R2
Interleaved execution?
12
Race Condition

• We would arrive at this incorrect state
• because we allowed both processes to manipulate
  the variable counter concurrently.
• Race Condition
• Several processes access and manipulate the same
  data concurrently and the outcome of the
  execution depends on the particular order in
  which the access takes place
• To prevent the race condition
• We need to ensure that only one process at a time
  can manipulate the variable counter
• We require that the processes be synchronized in
  some way

13
Critical-Section (CS) Problem

• A system consisting of n processes P0, P1, ,
  Pn-1
• Each process has a segment of code, called a
  critical section, where the process may change
  common variables, updating a table, writing a
  file, and so forth.
• The system requires that no two processes are
  executing in their critical section at the same
  time.
• Solution to the critical-section problem
• To design a protocol that the processes can use
  to cooperate.
• Each process must request permission to enter
  its CS.
• The section of code implementing this request is
  the entry section.
• The CS may be followed by an exit section
• The remaining code is the remainder section

14
Critical-Section Problem

• The general structure of a typical process Pi

Do entry section critical
section exit section remainder section
while ( TRUE )
15
Solution to Critical-Section Problem

• A solution to the critical-section problem must
  satisfy the following three requirements
• 1. Mutual Exclusion - If process Pi is executing
  in its critical section, then no other processes
  can be executing in their critical sections
• 2. Progress - If no process is executing in its
  critical section and there exist some processes
  that wish to enter their critical section, then
  the selection of the processes that will enter
  the critical section next cannot be postponed
  indefinitely deadlock-free condition
• 3. Bounded Waiting - A bound must exist on the
  number of times that other processes are allowed
  to enter their critical sections after a process
  has made a request to enter its critical section
  and before that request is granted
  starvation-free condition
• Assume that each process executes at a nonzero
  speed
• No assumption concerning relative speed of the n
  processes

16
Petersons Solution for critical section problem

• Two process Pi, Pj solution
• Software-based solution
• Assume that the LOAD and STORE instructions are
  atomic that is, cannot be interrupted.
• The two processes share two variables
• int turn
• Boolean flag2
• The variable turn indicates whose turn it is to
  enter the critical section.
• The flag array is used to indicate if a process
  is ready to enter the critical section. flagi
  true implies that process Pi is ready!

17
Algorithm for Process Pi

• do
• flagi TRUE
• turn j
• while ( flagj turn j)
• CRITICAL SECTION
• flagi FALSE
• REMAINDER SECTION
• while (TRUE)

// entry section
// exit section
18
Petersons Solution satisfies 3 conditions

• Mutual Exclusion
• Each Pi enters its critical section only if
  either flagjfalse or turni.
• Each Pi enters its critical section with
  flagitrue
• Both Pi and Pj cannot enter their critical
  section at the same time.
• Progress
• Pi can be stuck only if either flagjtrue and
  turnj.
• Bounded Waiting
• Pi will enter the critical section after at most
  one entry by Pj .

19
What is the problem in the Pi?

• do
• while (turn ! i)
• CRITICAL SECTION
• turn j
• REMAINDER SECTION
• while (TRUE)

satisfies Mutual Exclusion does not
satisfy Progress Bounded Waiting
do flagi true while (flagj)
CRITICAL SECTION
flagi false
REMAINDER SECTION while (TRUE)
satisfies Mutual Exclusion does not
satisfy Progress Bounded Waiting
20
Dekkers Algorithm two-process solution

• do
• flagi TRUE
• while (flagj )
• if ( turn j )
• flagi FALSE
• while ( turn j)
• flagi TRUE
• CRITICAL SECTION
• turn j
• flagi FALSE
• REMAINDER SECTION
• while (TRUE)

21
Synchronization Hardware

• Many systems provide hardware support for
  critical section code
• Uni-processors could disable interrupts
• Currently running code would execute without
  preemption
• Generally too inefficient on multiprocessor
  systems
• Operating systems using this are not broadly
  scalable
• Modern machines provide special atomic hardware
  instructions
• Atomic non-interruptible
• Test memory word and set value TestAndSet()
• Swap contents of two memory words Swap()

22
TestAndSet() Instruction

• Definition
• This Instruction is atomic
• This Instruction is provided by hardware.

• boolean TestAndSet (boolean target)
• boolean rv target
• target TRUE
• return rv

23
Solution using TestAndSet()

• Shared Boolean variable lock., initialized to
  false.
• Solution for Mutual Exclusion

do while ( TestAndSet (lock ) ) //
do nothing CRITICAL SECTION
lock FALSE
REMAINDER SECTION while ( TRUE)
busy waiting
24
Swap() Instruction

• Definition
• This Instruction is atomic
• This Instruction is provided by hardware.

void Swap (boolean a, boolean b)
boolean temp a a b
b temp
25
Solution using Swap()

• Shared Boolean variable lock initialized to
  FALSE
• Each process has a local Boolean variable key.
• Solution for Mutual Exclusion

do key TRUE while ( key
TRUE) Swap (lock, key
) CRITICAL SECTION lock
FALSE REMAINDER SECTION while ( TRUE)
busy waiting
26
Solution using TestAndSet()

• Shared Boolean variable waitingn and lock
  initialized to FALSE
• Each process has a local Boolean variable key.
• Solution for Bounded Waiting

do waiting i TRUE key TRUE
while ( waiting i key ) key TestAndSet
(lock) waiting i FALSE CRITICAL
SECTION j (i1)n while ( (j ! i)
!waitingj ) j(j1)n if( j i) lock
FALSE else waiting i FALSE REMAINDER
SECTION while ( TRUE)
busy waiting
27
Semaphore

• Semaphore Alphabet

28
Semaphore

• The various hardware-based solutions to the
  critical section problem
• TestAndSet(), Swap()
• complicated for application programmers to use
• To overcome this difficulty
• Semaphore may be used.
• Semaphore is
• Synchronization tool that does not require busy
  waiting
• Semaphore S integer variable
• Two standard operations to modify S wait() and
  signal()
• Originally called P() for wait() and V() for
  signal()
• The modification of the semaphore is atomic.
• less complicated to use.

29
Semaphore

• Definition for wait(S)
• Definition for signal(S)
• All the modification to the semaphore is atomic.
• When one process modifies the semaphore value, no
  other process can simultaneously modify that same
  semaphore value.

wait (S) while ( S lt 0 ) // no-op S--
busy waiting
signal (S) S
30
Usage of Semaphore

• Counting semaphore
• Integer value can range over an unrestricted
  domain
• Ex. 0 .. 10
• Binary semaphore
• Integer value can range only between 0 and 1
• Which is refer to as mutex locks
• Binary semaphore for solving the
  critical-section problem for multiple processes
• n processes share a semaphore, mutex.
• mutex is initialized to 1
• The structure of a process Pi

do wait (mutex) CRITICAL SECTION
signal (mutex) REMAINDER SECTION while
(TRUE)
31
1. binary semaphore

• Does previous code satisfy three requirements of
  CS problem.
• Mutual exclusion
• Progress
• Bounded waiting
• The third requirement is not guaranteed as a
  default.
• It usually depends on the implementation of
  wait() function.
• Ex, Linux sem_wait() does not guarantee the
  bounded waiting req.

32
Usage of Semaphore

• Counting semaphore used to control access to a
  given resource consisting of a finite number of
  instances
• Semaphore is initialized to the number of
  resources available
• To use a resource, a process performs wait()
• To release a resource, a process perform signal()
• When the semaphore is 0, all resources are being
  used.
• Counting semaphore to solve various
  synchronization problems.
• Ex. Two concurrently running processes P1, P2
• P1 with a statement S1, P2 with a statement S2
• S2 is executed only after S1 has completed
• How to solve this using semaphore?

33
Usage of Semaphore

• Solution of 3 in previous page
• Initialization
• P1 structure
• P2 structure

Semaphore synch 0
S1 signal (synch)
wait (synch) S2
34
Semaphore Implementation with Busy waiting

• must guarantee that no two processes can execute
  wait () and signal () on the same semaphore at
  the same time
• Thus, implementation becomes the critical section
  problem where the wait and signal code are placed
  in the critical section.
• Previous codes have busy waiting in critical
  section implementation
• While a process in critical section, others must
  loop continuously in wait code.
• called a spinlock
• Disadvantage
• waists CPU cycle during wait()
• Sometimes it is useful
• No context switch involved in the wait(),
  signal()
• Implementation code is short
• Little busy waiting if critical section rarely
  occupied
• However, applications may spend lots of time in
  critical sections and therefore this is not a
  good solution.

35
Semaphore Implementation with no Busy waiting

• To overcome the busy waiting problem, two
  operations are used
• Block() place the process invoking the
  operation on the appropriate waiting queue.
• Wakeup() remove one of processes in the waiting
  queue and place it in the ready queue.
• When a semaphore value is not positive on
  executing wait(), the process blocks itself
  instead of busy waiting.
• signal() operation wakes up a waiting process.
• To implement semaphores under this definition, we
  define a semaphore as a record like
• With each semaphore there is an associated
  waiting queue.

typedef struct int value
// semaphore value struct
process list // pointer to the PCB list
of waiting processes
36
Semaphore Implementation with no Busy waiting

• How to implement the waiting queue of a
  semaphore?
• linked list in the semaphore
• contains PCBs of waiting processes.
• The negative value meansthe number of waiting
  processes
• The positive value meansthe number of available
  resources
• The list can use any queuing strategy.
• To satisfy the bounded waiting requirementsthe
  queue can be implemented with FIFO queue.
• Two pointer variables which indicate head and
  tails of the PCB list.

37
Semaphore Implementation with no Busy waiting

• Implementation of wait()
• Implementation of signal()

wait ( semaphore S) S-gtvalue --
if ( S-gtvalue lt 0 ) add
this process to S-gtlist // put the PCB into
waiting queue block()
// go to waiting state
from running state
signal ( semaphore S) S-gtvalue
if ( S-gtvalue lt 0 )
remove a process P from S-gtlist // select a
process from waiting queue
wakeup()
// put the process into ready queue
38
Deadlock and Starvation

• Deadlock two or more processes are waiting
  indefinitely for an event that can be caused by
  only one of the waiting processes
• The use of a semaphore with a waiting queue may
  result in a deadlock.
• Let S and Q be two semaphores initialized to 1
• Starvation indefinite blocking. A process may
  never be removed from the semaphore queue in
  which it is suspended.
• The implementation of a semaphore with a waiting
  queue may result in a starvation.
• When the queue is in LIFO (last-in, first-out)
  order.

P0 wait (S) wait (Q) signal (S) signal
(Q)
P1 wait (Q) wait (S) signal (Q) signal
(S)
39
Classical Problems of Synchronization

• Bounded-Buffer Problem
• Readers and Writers Problem
• Dining-Philosophers Problem

40
Bounded-Buffer Problem

• More than two producers
• produce one item, store it in the buffer, and
  continue.
• More than two consumers
• consume a item from buffer, and continue.
• The buffer contains at most N items.
• Solution with semaphore
• Semaphore mutex initialized to the value 1
• Semaphore full initialized to the value 0
• Semaphore empty initialized to the value N.

41
Bounded Buffer Problem

• The structure of the producer process

do // produce an item
wait (empty)
// check buffer is full or not
wait (mutex)
// enter critical section // add
the item to the buffer // critical
section signal (mutex)
// exit critical section
signal (full)
// one item is produced while (TRUE)
42
Bounded Buffer Problem

• The structure of the consumer process

do wait (full)
// check buffer is empty
or not wait (mutex)
// enter critical section
// add the item to the buffer
// critical section signal (mutex)
// exit critical
section signal (empty)
// one item is produced
// consume the item while
(TRUE)
43
Readers-Writers Problem

• A data set is shared among a number of concurrent
  processes
• Readers only read the data set they do not
  perform any updates
• Writers can both read and write.
• Problem allow multiple readers to read at the
  same time. Only one single writer can access the
  shared data at the same time.
• Shared Data
• Data set
• Semaphore mutex initialized to 1.
• Semaphore wrt initialized to 1.
• Integer readcount initialized to 0.

44
Readers-Writers Problem

• The structure of a writer process

do wait (wrt)
// enter a critical
section // writing is
performed // critical section
signal (wrt)
// exit critical section
while (TRUE)
45
Readers-Writers Problem

• The structure of a reader process

do wait (mutex)
readcount if (
readcount 1 ) wait(wrt) // when
it is the first reading
signal(mutex) // reading is
performed // more than two
reader can read
//
concurrently wait(mutex)
readcount -- if ( readcount 0
) signal(wrt) // when it is the last
reading signal (mutex)
while (TRUE)
46
Readers-Writers Problem

• Starvation is the problem
• The writer may starve.
• No readers will be kept waiting unless a writer
  has already obtained permission to use the shared
  object.
• Another variation of Readers-Writers Problem
• Once a writer is ready, that the writer performs
  its write as soon as possible
• If a writer is waiting to access the object, no
  new readers may start reading
• gt In this case, the readers may starve.
• What is the starvation free solution for
  Readers-Writers Problem?

47
Dining-Philosophers Problem

• Five philosophers who spend their lives thinking
  and eating.
• They share a circular table surrounded by five
  chairs.
• In the center of the table is a bowl of rice.
• File single chopsticks on the table.
• When a philosophers think, she does not interact
  with neighbors.
• From time to time, she gets hungry andtry to
  pick up the two chopsticks that areclosest to
  her.
• She picks up only one chopsticksat a time.
• She cannot pick up the chopstick that is already
  in the hand of a neighbor.
• When she gets two chopsticks, she eats without
  releasing them.
• When she finished eating, she put down both
  chopsticks and think again.
• How to implement this with concurrent processors
  in a deadlock-free and starvation-free manner?

48
Dining-Philosophers Problem

• It is a large class of concurrency-control
  problems.
• It is a simple representation of the need to
  allocate several resources among several
  processes in a deadlock-free and starvation-free
  manner.
• Simple Solution
• Shared data
• Bowl of rice (data set)
• Semaphore chopstick 5 initialized to 1

49
Dining-Philosophers Problem (Cont.)

• This solution guarantees that
• No two neighbors are eating simultaneously
• However, this solution creates deadlock.
• Suppose all five philosophers become hungry
  simultaneously and each grabs her left
  chopsticks.
• All chopsticks are taken.
• When each philosophers tries to grab her right
  chopstick, she delays forever
• Possible deadlock free solutions
• Allow at most four philosophers to be sitting
  together
• Allow a philosopher to pick up her chopsticks
  only if both chopsticks are available
• Use an asymmetric solution an odd one picks up
  left chopstick first, an even one picks up right
  chopstick first.

50
Problems with Semaphores

• Be careful not to misuse the semaphore.
• Examples of misuse
• mutex is a semaphore which is initialized to 1
• signal (mutex) . wait (mutex)
• results in a violation of the mutual exclusion
  requirement
• wait (mutex) wait (mutex)
• results in deadlock
• Omitting of wait (mutex) or signal (mutex) (or
  both)
• Either mutual exclusion is violated or a deadlock
  will occur
• To deal with such errors, the monitor may be used.

51
Monitors

• A high-level abstraction that provides a
  convenient and effective mechanism for process
  synchronization
• Monitor is defined as an abstract data type
  like class in object-oriented language (C,
  Java)
• A monitor instance is shared among multiple
  processes.
• Only one process may be active within the
  monitor at a time

monitor monitor-name shared variable
declarations procedure P1 () .
procedure Pn ()
Initialization code ( .)
Private Data
Public Methods
Initialization Method
52
Schematic view of a Monitor

• Shared data
• Operations
• Initialization code
• The shared data can be accessed by operations
• Only one process is active within a monitor at a
  time
• Programmer dont need to code this
  synchronization.

53
Condition Variables

• Basic monitor is not sufficiently powerful for
  modeling some synchronization schemes.
• To solve, condition variables are introduced.
• condition x, y
• A programmer can define one or more variables of
  type condition
• Two operations on a condition variable
• x.wait () a process that invokes the operation
  is suspended.
• x.signal () resumes one of processes (if any)
  that invoked x.wait ()
• x.signal() resumes exactly one suspended process.
  
• If no process is suspended, then nothing happens.

54
Monitor with Condition Variables
55
Solution to Dining Philosophers
monitor DP enum THINKING HUNGRY, EATING)
state 5 condition self 5 void pickup
(int i) statei HUNGRY
test(i) if (statei ! EATING) self
i.wait() void putdown (int i)
statei THINKING // test
left and right neighbors test((i 4)
5) test((i 1) 5)
Three stats of a philosopher
Ph_i delays herself when she is hungry and unable
to pick both chopsticks
Ph_i invokes the operation pickup(i) before she
eat.
Ph_i invokes the operation putdown(i) after she
eat.
56
Solution to Dining Philosophers (cont)
void test (int i) if ( (state(i
4) 5 ! EATING) (statei
HUNGRY) (state(i 1) 5 !
EATING) )
statei EATING selfi.signal ()
initialization_code()
for (int i 0 i lt 5 i)
statei THINKING
Ph_i invokes the test(i) to pickup
chopsticks. Ph_i invokes the test(i1) and
test((i1)5) to release her chopsticks. When two
neighbors are not eating, she changes its state
to EATING and invoke her.
Initialize all the Ph with THINKING state.
57
Solution to Dining Philosophers (cont)

• A philosopher_i must invoke the operation
  pickup() and putdown() in the following sequence.

do thinking dp.pickup( i ) eat. dp.putdo
wn ( i ) while (TRUE)
58
Solution to Dining Philosophers (cont)
pickup() putdown()
entry queue
condition variable queue
self1
shared data
self2
operations
pickup()
putdown()
test()
initialization_code()
59
Summary

• Cooperating processes that share data have
  critical section of code each of which is in use
  by only one process at a time.
• Solutions for critical section problem
• Software-based solution Petersons algorithm,
  Bakery algorithm
• Hardware-based solution Testandset(), Swap()
• Three requirements for critical section problem
• Mutual Exclusion, Progress, Bounded Wating
• The main disadvantage of these solution is that
  they all require busy waiting. Semaphore overcome
  this difficulty.
• Semaphore can be used to solve various
  synchronization problems
• The bounded-buffer, The readers-writers, The
  dining-philosophers problem problems
• Those are examples of a large class of
  concurrency-control problems.
• The solution should be deadlock-free ad
  starvation-free.
• Monitors provides the synchronization mechanism
  for sharing abstract data types.
• Condition variables provide a method by which a
  monitor procedure can block its execution until
  it is signaled to continue.

60
End of Chapter 6