Chapter 7 Process Synchronization

1
Chapter 7 Process Synchronization
2
Outline

• Background
• The Critical-Section Problem
• Synchronization Hardware
• Semaphores
• Classical Problems of Synchronization
• Critical Regions
• Monitors
• OS Synchronization
• Atomic Transactions

3
Background

• Concurrent processes (or threads) often need to
  share data (maintained either in shared memory or
  files) and resources
• If there is no controlled access to shared data,
  some processes will obtain an inconsistent view
  of this data
• The action performed by concurrent processes will
  then depend on the order in which their execution
  is interleaved
• Maintaining data consistency requires mechanisms
  to ensure the orderly execution of cooperating
  processes.
• Shared-memory solution to bounded-butter problem
  has a race condition on the class data count

4
Bounded Buffer
5
Bounded Buffer (Cont.)
6
Bounded Buffer (Cont.)
7
Race Condition

• Race condition several processes concurrently
  access and manipulate the same data
• Outcome of the execution relies on the particular
  order in which the access takes place
• We need to ensure only one process at a time can
  be manipulating the shared data
• Process synchronization and coordination

• (P) counter counter 1
• register1 counter
• register1 register1 1
• counter register1
• (C) counter counter -1
• register2 counter
• register2 register2 -1
• counter register2

8
Race Condition (Example)

• Currently ? counter5
• T0 producer register1 counter register1
  5
• T1 producer register1 register1 1
  register1 6
• T2 consumer register2 counter register2
  5
• T3 consumer register2 register2 -1 register2
  4
• T4 producer counter register1 counter 6
• T5 consumer counter register2 counter 4

Both processes manipulate the variable counter
concurrently.
9
The Critical Section Problem

• n processes all competing to use some shared data
• Each process has a code segment, called critical
  section (CS), in which the shared data is
  accessed.
• Problem ensure that when one process is
  executing in its critical section, no other
  process is allowed to execute in its critical
  section
• Even with multiple CPUs
• Each process must request the permission to
  enter its CS

10
The Critical Section Problem (Cont.)

• The section of code implementing this request is
  called the entry section
• The critical section (CS) might be followed by an
  exit section
• The remaining code is the remainder section
• The critical section problem is to design a
  protocol that the processes can use so that their
  action will not depend on the order in which
  their execution is interleaved (possibly on many
  processors)

11
Framework for analysis of solutions

• Each process executes at nonzero speed but no
  assumption on the relative speed of N processes
• General structure of a process

• Many CPUs may be present but memory hardware
  prevents simultaneous access to the same memory
  location
• No assumption about order of interleaved
  execution
• For solutions we need to specify entry and exit
  sections
• Processes may share some common variables to
  synchronize their actions.

12
Requirements for a Valid Solution to Critical
Section Problem

• Mutual Exclusion
• At any time, at most one process can be in its
  critical section (CS)
• Progress If no process is executing in its CS
  and there exist some processes that wish to enter
  their CS
• Only processes that are not executing in their RS
  can participate in the decision of who will enter
  next in the CS.
• This selection cannot be postponed indefinitely
• Bounded Waiting
• After a process has made a request to enter its
  CS, there is a bound on the number of times that
  the other processes are allowed to enter their CS
  and before that request is granted
• otherwise the process will suffer from starvation

13
Types of solutions

• Software solutions
• Algorithms whose correctness does not rely on any
  other assumptions (see framework)
• Hardware solutions
• Rely on some special machine instructions
• Operation System solutions
• Provide some functions and data structures to the
  programmer

14
Software solutions

• We consider first the case of 2 processes
• Algorithm 1 and 2 are incorrect
• Algorithm 3 is correct (Petersons algorithm)
• Then we generalize to n processes -- Bakery
  algorithm
• Notation
• We start with 2 processes P0 and P1
• When presenting process Pi, Pj always denotes the
  other process (i ! j)

15
Algorithm 1
16
Algorithm (Cont.)
Process P1 Do while(turn!1) CS
turn0 RS While (1)
Process P0 Do while(turn!0) CS
turn1 RS While (1)

• Ex P0 has a large RS and P1 has a small RS. If
  turn0, P0 enter its CS and then its long RS
  (turn1). P1 enter its CS and then its RS
  (turn0) and tries again to enter its CS request
  refused! He has to wait that P0 leaves its RS.

17
Algorithm 2
18
Algorithm 3 (Petersons algorithm)
19
Petersons Algorithm Global View
Process P0 Do flag0true // 0 wants
in turn 1 // 0 gives a chance to 1
while (flag1turn1) CS
flag0false // 0 no longer wants in
RS While (1)
Process P1 Do flag1true // 1 wants
in turn0 // 1 gives a chance to 0
while (flag0turn0) CS
flag1false // 1 no longer wants in
RS While (1)
20
Algorithm 3 Proof of Correctness

• Mutual exclusion is preserved since
• P0 and P1 are both in CS only if flag0
  flag1 true and only if turn i for each Pi
  (impossible)
• We now prove that the progress and bounded
  waiting requirements are satisfied
• Pi cannot enter CS only if stuck in while() with
  condition flag j true and turn j.
• If Pj is not ready to enter CS then flag j
  false and Pi can then enter its CS

21
Algorithm 3 proof of correctness (cont.)

• If Pj has set flag jtrue and is in its
  while(), then either turni or turnj
• If turni, then Pi enters CS. If turnj then Pj
  enters CS but will then reset flag jfalse on
  exit allowing Pi to enter CS
• but if Pj has time to reset flag jtrue, it
  must also set turni
• since Pi does not change value of turn while
  stuck in while(), Pi will enter CS after at most
  one CS entry by Pj (bounded waiting)

22
What about Process Failures?

• If all 3 criteria (ME, progress, bounded waiting)
  are satisfied, then a valid solution will provide
  robustness against failure of a process in its
  remainder section (RS)
• since failure in RS is just like having an
  infinitely long RS
• However, no valid solution can provide robustness
  against a process failing in its critical section
  (CS)
• A process Pi that fails in its CS does not signal
  that fact to other processes for them Pi is
  still in its CS

23
N-process Solution Bakery Algorithm

• Before entering their CS, each Pi receives a
  number. Holder of smallest number enter CS (like
  in bakeries, ice-cream stores...)
• When Pi and Pj receives same number
• if iltj then Pi is served first, else Pj is served
  first
• Pi resets its number to 0 in the exit section
• The numbering scheme always generates numbers in
  increasing order of enumeration i.e.,
  1,2,3,3,3,3,4,5...
• Notation
• (a,b) lt (c,d) if a lt c or if a c and b lt d
• max(a0,...ak) is a number b such that
• b gt ai for i0,..k

24
The Bakery algorithm (cont.)

• Shared data
• choosing array0..n-1 of boolean
• initialized to false
• number array0..n-1 of integer
• initialized to 0
• Correctness relies on the following fact
• If Pi is in CS and Pk has already chosen its
  numberk! 0, then (numberi,i) lt (numberk,k)
  
• but the proof is somewhat tricky...

25
The Bakery Algorithm (Cont.)
((numberj, j) lt (numberi, i)))
26
Drawbacks of Software Solutions

• Processes that are requesting to enter in their
  critical section are busy waiting (consuming
  processor time needlessly)
• If Critical Sections are long, it would be more
  efficient to block processes that are waiting...

27
Hardware Solutions Interrupt Disabling

• On a uniprocessor mutual exclusion is preserved
  but efficiency of execution is degraded while in
  CS, we cannot interleave execution with other
  processes that are in RS
• On a multiprocessor mutual exclusion is not
  preserved
• CS is now atomic but not mutually exclusive
• Generally not an acceptable solution

Process Pi repeat disable interrupts
critical section enable interrupts remainder
section forever
28
Hardware Solutions Special Machine Instructions

• Normally, access to a memory location excludes
  other access to that same location
• Extension designers have proposed machines
  instructions that perform 2 actions atomically
  (indivisible) on the same memory location (ex
  reading and writing)
• The execution of such an instruction is also
  mutually exclusive (even with multiple CPUs)
• They can be used to provide mutual exclusion but
  need to be complemented by other mechanisms to
  satisfy the other 2 requirements of the CS
  problem (and avoid starvation and deadlock)

29
The test-and-set instruction

• Test and modify the content of a word atomically.

• Shared data var lock boolean (initially false)

30
The test-and-set instruction (cont.)

• Mutual exclusion is preserved if Pi enter CS,
  the other Pj are busy waiting
• When Pi exit CS, the selection of the Pj who will
  enter CS is arbitrary no bounded waiting. Hence
  starvation is possible
• Processors (ex Pentium) often provide an atomic
  swap(a,b) instruction that swaps the content of a
  and b.
• But swap(a,b) suffers from the same drawbacks as
  test-and-set

31
Swap for Mutual Exclusion

• Shared variable lock is initialized to false
• Each Pi has a local variable key
• The only Pi that can enter CS is the one who
  finds lockfalse
• This Pi excludes all the other Pj by setting lock
  to true

32
Bounded-Waiting Mutual Exclusion with TestAndSet

• Common data structures initialized to false
• boolean waitingn
• boolean lock
• Mutual Exclusion Pi can enter CS only if either
  waitingifalse or keyfalse
• key becomes false only if TestAndSet is executed
• First process to execute TestAndSet find
  keyfalse others wait
• waitingi becomes false only if other process
  leaves CS
• Only one waitingi is set to false
• Progress similar to mutual exclusion
• Bounded waiting waiting in the cyclic order

33
Bounded-Waiting Mutual Exclusion with TestAndSet
(Cont.)
34
Semaphore
35
Overview -- Semaphore

• Synchronization tool (provided by the OS) that
  does not require busy waiting
• A semaphore S is an integer variable that, apart
  from initialization, can only be accessed through
  2 atomic and mutually exclusive operations
• wait(S) -- P(S) in textbook
• signal(S) -- V(S) in textbook
• To avoid busy waiting when a process has to
  wait, it will be put in a blocked queue of
  processes waiting for the same event

36
Semaphore (Cont.)

• wait(S) decrements the semaphore value. If the
  value becomes negative, then the process
  executing the wait is blocked
• signal(S) increments the semaphore value. If the
  value is not positive, then a process blocked by
  a wait operation is unblocked.
• wait and signal are assumed to be atomic
• They cannot be interrupted and each routine can
  be treated as an indivisible step

37
Semaphore Implementation
38
Semaphore Implementation (Cont.)
39
Semaphore Implementation (Cont.)

• Hence, in fact, a semaphore is a record
  (structure)
• When a process must wait for a semaphore S, it is
  blocked and put on the semaphores queue
• The queue links PCB
• The signal operation removes (according to a fair
  policy like FIFO) one process from the queue and
  puts it in the list of ready processes
• Block and wakeup change process state they are
  basic system calls
• Block from running to waiting
• wakeup from waiting to ready

40
Mutual-Exclusion Implementation with Semaphores

• For n processes
• Initialize S.value to 1
• Then only 1 process is allowed into CS (mutual
  exclusion)
• To allow k processes into CS, we initialize
  S.value to k

41
Using semaphores to synchronize processes

• Two processes P1 and P2
• Statement S1 in P1 needs to be performed before
  statement S2 in P2
• Then define a semaphore synch
• Initialize synch to 0

• Proper synchronization is achieved by having in
  P1
• S1
• signal(synch)
• And having in P2
• wait(synch)
• S2

42
Semaphores Observations

• When S.value gt0 the number of processes that
  can execute wait(S) without being blocked
  S.value
• When S.valuelt0 the number of processes waiting
  on S is S.value
• Atomicity and mutual exclusion no 2 process can
  be in wait(S) and signal(S) (on the same S) at
  the same time (even with multiple CPUs)
• Hence the blocks of code defining wait(S) and
  signal(S) are, in fact, critical sections

43
Semaphores Observations (Cont.)

• Wait and Signal must be executed atomically
  (mutual execution)
• The critical sections defined by wait(S) and
  signal(S) are very short typically 10
  instructions
• Solutions
• uniprocessor disable interrupts during these
  operations (ie for a very short period). This
  does not work on a multiprocessor machine.
• multiprocessor use previous software or hardware
  schemes. The amount of busy waiting should be
  small.

44
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.
• Let S and Q be two semaphores initialized to 1
• P0 P1
• P(S) P(Q)
• P(Q) P(S)
• ? ?
• V(S) V(Q)
• V(Q) V(S)
• Starvation (or indefinite blocking) may occur if
  we add and remove processes from the semaphore
  queue in LIFO order

45
Two Types of Semaphores

• Counting semaphore integer value can range over
  an unrestricted domain.
• Binary semaphore integer value can range only
  between 0 and 1 can be simpler to implement.
• Can implement a counting semaphore S as a binary
  semaphore.

46
Implementing A Counting Semaphore (S) as A Binary
Semaphore
47
Implementing A Counting Semaphore (S) as A Binary
Semaphore (Cont.)
48
Classical Problems of Synchronization

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

49
Bounded-Buffer Problem

• Shared data
• Semaphore full, empty, mutex
• Initially
• full 0 empty n mutex 1

50
Bounded-Buffer Problem (Cont.) Producer
51
Bounded-Buffer Problem (Cont.)
52
The Dining Philosophers Problem

• 5 philosophers who only eat and think
• Each needs to use 2 forks for eating
• We have only 5 forks
• Illustrates the difficulty of allocating
  resources among process without deadlock and
  starvation

53
The Dining Philosophers Problem (Cont.)
Shared data semaphore chopstick5 Initially,
all values are 1
54
The Dining Philosophers Problem (Cont.)

• The preliminary solution may cause deadlock
• When all philosophers become hungry
  simultaneously, and each grabs her left chopstick
• Possible remedies to deadlock
• Allow at most four philosophers to be sitting
  simultaneously
• Allow a philosopher to pick up her chopsticks
  only if both chopsticks are available (to do this
  she must pick them up in a CS)
• An odd philosopher picks up first her left
  chopstick and then her right chopstick, whereas
  an even philosopher picks up first her right
  chopstick and then her left chopstick
• May starvation

55
Readers-Writers Problem

• Shared data
• var mutex, wrt semaphore (1)
• readcount integer (0)
• Writer process
• wait(wrt)
• writing is performed
• signal(wrt)

56
Readers-Writers Problem (Cont.) -- Reader

• mutex protect readcount
• wrt
• Mutual exclusion for writers
• Used by the first or last reader that enters or
  exits CS
• If a writer is in CS and n readers are waiting,
  then one reader is queued on wrt, and n-1 readers
  are queued on mutex
• When a writer executes signal(wrt), we may resume
  the execution of either the waiting readers or a
  single waiting writer ? scheduler

(wrt)
57
Problems with semaphores

• Semaphores provide a powerful tool for enforcing
  mutual exclusion and coordinate processes
• But wait(S) and signal(S) are scattered among
  several processes. Hence, difficult to understand
  their effects
• Usage must be correct in all the processes
• One bad (or malicious) process can fail the
  entire collection of processes

signal(mutex)critical sectionwait(mutex)
wait(mutex)critical sectionwait(mutex)
signal(mutex)critical sectionsignal(mutex)
58
Critical Region

• A high-level language construct
• Also called conditional critical region (CCR)
• Assume a process consists of some local data, and
  a sequential program that can operate on the data
• Local data can be accessed by only the sequential
  program that is encapsulated within the same
  process
• Assume shared global data
• v shared T (A variable v of type T to be shared
  among processes)

59
Critical Region (Cont.)

• Critical region region v when (B) S
• Statements S mutual exclusion
• Boolean expression B can enter S only if B is
  true
• If B is false, the process relinquishes the
  mutual exclusion, and is delayed until B becomes
  true and no other process is in the region
  associated with v

60
Critical Region for Bounded-Buffer
Producer-Consumer
Shared Data
Producer
Consumer
61
Critical Region Implementation

• CCR must be translated by a compiler to
  semaphores
• semaphore mutex, first_delay, second_delay
• Mutual exclusion to CS mutex (initialize to 1)
• If a process cannot enter CS because B is false,
  initially wait on first_delay (initialize to 0)
• A process waiting on first_delay is moved to
  second_delay (initialize to 0) before it is
  allowed to reevaluate its B
• When a process leaves CS, it may influence B of
  other processes
• Trace through first_delay and second_delay (in
  that order)

62
Critical Region Implementation (Cont.)

• Keep track of the number of processes waiting on
  first-delay and second-delay, with first-count
  and second-count, respectively.
• The algorithm assumes a FIFO ordering in the
  queuing of processes for a semaphore.
• For an arbitrary queuing discipline, a more
  complicated implementation is required.

63
Implementation of CCR
CCR Implementationusing semaphores
64
Monitor

• High-level language constructs that provide
  equivalent functionality to that of semaphores
  but are easier to control
• Found in many concurrent programming languages
• Concurrent Pascal, Modula-3, uC, Java...
• Can be implemented by semaphores...

65
Monitor

• Is a software module containing
• One or more procedures
• An initialization sequence
• Local data variables
• Characteristics
• Local variables accessible only by monitors
  procedures
• A process enters the monitor by invoking one of
  its procedures
• Only one process can be in the monitor at any one
  time
• Mutual Exclusion is enforced implicitly

66
Monitor Structure
67
Monitor

• The monitor ensures mutual exclusion no need to
  program this constraint explicitly
• Hence, shared data are protected by placing them
  in the monitor
• The monitor locks the shared data on process
  entry
• Process synchronization is done by the programmer
  by using condition variables that represent
  conditions a process may need to wait for before
  executing in the monitor

68
Condition Variables

• Local to the monitor (accessible only within the
  monitor)
• Can be accessed and changed only by two
  functions
• cwait(a) blocks execution of the calling process
  on condition (variable) a
• the process can resume execution only if another
  process executes csignal(a)
• csignal(a) resume execution of some process
  blocked on condition (variable) a.
• If several such process exists choose any one
• If no such process exists do nothing

69
Cwait and Csignal

• Awaiting processes are either in the entrance
  queue or in a condition queue
• A process puts itself into condition queue cn by
  issuing cwait(cn)
• csignal(cn) brings into the monitor 1 process in
  condition cn queue
• Hence csignal(cn) blocks the calling process and
  puts it in the urgent queue (unless csignal is
  the last operation of the monitor procedure)

70
(No Transcript)
71
Solution to Dining Philosophers

• type dining-philosophers monitor
• var state array 0..4 of (thinking, hungry,
  eating)
• var self array 0..4 of condition
• procedure pickup (i 0..4)
• begin
• statei hungry
• test (i)
• if statei ? eating then selfi.wait
• end

72
Solution to Dining Philosophers (Cont.)

• procedure putdown (i 0..4)
• begin
• statei thinking
• test (i4 mod 5)
• test (i1 mod 5)
• end

73
Solution to Dining Philosophers (Cont.)

• procedure test(k 0..4)
• begin
• if statek4 mod 5 ? eating and statek
  hungry and statek1 mod 5 ? eating
• then begin
• statek eating
• selfk.signal
• end
• end

• begin
• for i 0 to 4 do
• statei thinking
• end.

74
Monitor Implementation Using Semaphores
75
Monitor Implementation
76
Monitor Implementation
77
Correctness of Monitor Usage

• Check two conditions to establish correctness of
  system
• User processes must always make their calls on
  the monitor in a correct sequence
• Must ensure that an uncooperative process does
  not ignore the mutual-exclusion gateway provided
  by the monitor, and try to access the shared
  resource directly, without using the access
  protocols

78
Solaris 2 Synchronization

• Implements a variety of locks to support
  multitasking, multithreading (including real-time
  threads), and multiprocessing.
• Uses adaptive mutexes for efficiency when
  protecting data from short code segments.
• Uses condition variables and readers-writers
  locks when longer sections of code need access to
  data.
• Uses turnstiles to order the list of threads
  waiting to acquire either an adaptive mutex or
  reader-writer lock.

79
Windows 2000 Synchronization

• Uses interrupt masks to protect access to global
  resources on uniprocessor systems
• Uses spinlocks on multiprocessor systems.
• Also provides dispatcher objects which may act as
  wither mutexes and semaphores.
• Dispatcher objects may also provide events. An
  event acts much like a condition variable.