Process Synchronization Continued

1
Process SynchronizationContinued

• 7.2 Critical-Section Problem
• 7.3 Synchronization Hardware
• 7.4 Semaphores

2
Critical section

• When a process executes code that manipulates
  shared data (or resource), we say that the
  process is in a critical section (CS) for that
  resource

repeat entry section critical section exit
section remainder section forever
3
Three Key Requirements for a Valid Solution to
the Critical Section Problem

• Mutual Exclusion At any time, at most one
  process can be executing critical section (CS)
  code
• Progress If no process is in its CS and there
  are one or more processes that wish to enter
  their CS, it must be possible for those
  processes to negotiate who will proceed next into
  CS
• No deadlock
• no process in its remainder section can
  participate in this decision
• Bounded Waiting After a process P has made a
  request to enter its CS, there is a limit on the
  number of times that the other processes are
  allowed to enter their CS, before Ps request is
  granted
• Deterministic algorithm, otherwise the process
  could suffer from starvation

4
turn 0 Process P0 repeat
while(turn!0) CS turn1
RS forever
Process P1 repeat while(turn!1) CS
turn0 RS forever
Faulty Algorithm 1 Turn taking ok for mutual
exclusion, but processes MUST strictly alternate
turns
5
flag1false Process P1 repeat
flag1true while(flag0) CS
flag1false RS forever
flag0false Process P0 repeat
flag0true while(flag1) CS
flag0false RS forever
Faulty Algorithm 2 - ready flag Mutual exlusion
ok, but not progress (interleaving flag1true
and flag0true means neither can enter CS)
6
Petersons Algorithm
flag0,flag1false turn 0 Process
P0 repeat flag0true // 0 wants in
turn 1 // 0 gives a chance to 1 while
(flag1turn1) CS flag0false //
0 is done RS forever
Process P1 repeat flag1true // 1
wants in turn0 // 1 gives a chance to
0 while (flag0turn0) CS
flag1false // 1 is done RS forever
Petersons algorithm proved to be correct Turn
can only be 0 or 1 even if both flags are set to
true
7
N-Process Solution Bakery Algorithm

• Take a number for better service...
• Before entering the CS, each Pi takes a number.
• Holder of smallest number enters CS next
• ..but more than one process can get the same
  number
• If Pi and Pj receive same number
• lowest numbered process is served first
• Process resets its number to 0 in the exit section

8
Bakery Algorithm

• Shared data
• choosing array0..n-1 of boolean
• initialized to false
• number array0..n-1 of integer
• initialized to 0

9
Bakery Algorithm
Process Pi repeat choosingitrue
numberimax(number0..numbern-1)1
choosingifalse for j0 to n-1 do
while (choosingj) while (numberj!0
and (numberj,j)lt(numberi,i)) CS
numberi0 RS forever
10
Important Observation about Process Interleaving

• Even a simple high level language assignment
  statement can be interleaved

Two Machine instructions load R1, B store R1, A
One HLL statement A B
This is why it is possible to two processes to
take the same number
11
Bakery Algorithm Proof

• Mutual Exclusion
• If Pi is in CS and Pk has already chosen its
  number, then (numberi,i) lt (numberk,k)
• If they both had their numbers before the
  decision, this must be true or Pi would not have
  been chosen
• If Pi entered its CS before Pk got its number, Pk
  got a bigger number
• So Pk cannot enter its CS until Pi exits.
• Progress, Bounded Waiting
• Processes enter CS in FCFS order

12
Drawbacks of Software Solutions

• Complicated to program
• Busy waiting (wasted CPU cycles)
• It would be more efficient to block processes
  that are waiting (just as if they had requested
  I/O).
• This suggests implementing the permission/waiting
  function in the Operating System
• But first, lets look at some hardware approaches
  (7.3 Synchronization Hardware)

13
Hardware Solution 1 Disable Interrupts
Process Pi repeat disable interrupts
critical section enable interrupts remainder
section forever

• On a uniprocessor, mutual exclusion is preserved
  while in CS, nothing else can run
• because preemption impossible
• On a multiprocessor mutual exclusion is not
  achieved
• Interrupts are per-CPU
• Generally not a practical solution for user
  programs
• But could be used inside an OS

14
Hardware Solution 2 Special Machine Instructions

• Normally, the memory system restricts access to
  any particular memory word to one CPU at a time
• Useful extension
• machine instructions that perform 2 actions
  atomically on the same memory location (ex
  testing and writing)
• The execution of such an instruction is mutually
  exclusive on that location (even with multiple
  CPUs)
• These instructions can be used to provide mutual
  exclusion
• but need more complex algorithms for satisfying
  the requirements of progress and bounded waiting

15
The Test-and-Set Instruction

• An algorithm that uses testset for Mutual
  Exclusion
• Shared variable lock is initialized to 0
• Only the first Pi who sets lock enters CS

• Test-and-Set expressed in C

int testset(int i) int rv rv i i
1 return rv
Process Pi repeat while(testset(lock))
CS lock0 RS forever
Non Interruptible (atomic)! One instruction reads
then writes the same memory location
16
Test-and-Set Instruction

• Mutual exclusion is assured if Pi enters CS, the
  other Pj are busy waiting
• Satisfies progress requirement
• When Pi exits CS, the selection of the next Pj to
  enter CS is arbitrary no bounded waiting (its a
  race!).
• Starvation is possible.
• See Fig 7.10 for (complicated) solution
• Some processors (ex Pentium) provide an atomic
  Swap(a,b) instruction that swaps the content of a
  and b.
• (Same drawbacks as Test-and-Set)

17
Using Swap for Mutual Exclusion

• Shared variable lock is initialized to 0
• Each Pi has a local variable key
• The only Pi that can enter CS is the one which
  finds lock0
• This Pi excludes all other Pj by setting lock to
  1
• (Same effect as test-and-set)

Process Pi repeat key1 repeat
swap(lock,key) until key0 CS
lock0 RS forever
18
Operating Systems or Programming Language Support
for Concurrency

• Solutions based on machine instructions such as
  test and set involve tricky coding.
• We can build better solutions by providing
  synchronization mechanisms in the Operating
  System or Programming Language (7.4
  Semaphores).
• (This leaves the really tricky code to systems
  programmers)

19
Semaphores

• A Semaphore S is an integer variable that, apart
  from initialization, can only be accessed through
  2 atomic and mutually exclusive operations
• wait(S)
• sometimes called P()
• Dutch proberen to test
• signal(S)
• sometimes called V()
• Dutch verhogen to increment

20
Busy Waiting Semaphores

• The simplest way to implement semaphores.
• Useful when critical sections last for a short
  time, or we have lots of CPUs.
• S initialized to positive value (to allow someone
  in at the beginning).

wait(S) while Slt0 do S-- signal(S)
S
21
Atomicity in Semaphores

• The test-and-decrement sequence in wait must be
  atomic, but not the loop.
• Signal is atomic.
• No two processes can be allowed to execute atomic
  sections simultaneously.
• This can be implemented by other mechanisms (in
  the OS)
• test-and-set, or
• disable interrupts.

wait(S)
T
S lt 0
atomic
F
S - -
22
Using semaphores for solving critical section
problems

• For n processes
• Initialize semaphore mutex to 1
• Then only one process is allowed into CS (mutual
  exclusion)
• To allow k processes into CS at a time, simply
  initialize mutex to k

Process Pi repeat wait(mutex) CS
signal(mutex) RS forever
23
Semaphores in Action
Initialize mutex to 1
Process Pi repeat wait(mutex) CS
signal(mutex) RS forever
Process Pj repeat wait(mutex) CS
signal(mutex) RS forever
24
Synchronizing Processes using Semaphores

• Define a semaphore synch
• Initialize synch to 0
• Put this in P2
• wait(synch)
• S2
• And this in in P1
• S1
• signal(synch)

• Two processes
• P1 and P2
• Statement S1 in P1 needs to be performed before
  statement S2 in P2
• We want a way to make P2 wait
• until P1 tells it it is OK to proceed

25
Busy-Waiting Semaphores Observations

• When Sgt0
• the number of processes that can execute wait(S)
  without being blocked S
• When S0 one or more processes are waiting on S
• Semaphore is never negative
• When S becomes gt0, the first process that tests S
  enters enters its CS
• random selection (a race)
• fails bounded waiting condition