Concurrency: Mutual Exclusion and Synchronization

1
Concurrency Mutual Exclusion and Synchronization

• Chapter 5

2
Concurrency Design Issues

• Communication among processes
• Sharing resources
• Synchronization of multiple processes
• Allocation of processor time

3
Difficulties with Concurrency

• Sharing global resources
• Management of allocation of resources
• Programming errors difficult to locate

4
Operating System Concerns

• Keep track of active processes
• Allocate and deallocate resources
• processor time
• memory
• files
• I/O devices
• Protect data and resources
• Result of process must be independent of the
  speed of execution since other processes share
  the processor time

5
Control Problems

• Mutual Exclusion
• critical sections
• only one program at a time is allowed in its
  critical section
• example only one process at a time is allowed to
  send command to the printer
• Deadlock
• Starvation

6
Mutual Exclusion

• Requirements
• Mutual exclusion must be enforced
• Only 1 process at a time into critical section
  protected by same lock
• Process halting outside of both the critical
  section and the mutual exclusion code does not
  interfere with other processes
• No process requiring mutual exclusion must be
  delayed forever
• When no process is in a critical section, one
  process requesting entry must be permitted to
  enter without delay
• Assumptions
• No assumptions are made about relative process
  speeds or number of processors
• A process remains in its critical section for a
  finite time.

7
Software Implementation of Mutual Exclusion
Attempt 1
var turn 0..1 / shared /

• Process 0
• while (turn ! 0) do
• nothing
• ltcritical sectiongt
• turn 1

Process 1 while (turn ! 1) do nothing ltcritic
al sectiongt turn 0
mutual exclusion? progress?
8
Software Implementation of Mutual Exclusion
Attempt 2
var flag array0..1 of Boolean / initialize
both to false / / shared /

• Process 0
• while (flag1) do
• nothing
• flag0 true
• ltcritical sectiongt
• flag0 false

Process 1 while (flag0) do nothing flag1
true ltcritical sectiongt flag1 false
mutual exclusion? progress?
9
Software Implementation of Mutual Exclusion
Attempt 3
var flag array0..1 of Boolean / initialize
both to false / / shared /

• Process 0
• flag0 true
• while (flag1) do
• nothing
• ltcritical sectiongt
• flag0 false

Process 1 flag1 true while (flag0)
do nothing ltcritical sectiongt flag1 false
mutual exclusion? progress? (deadlock?)
10
Software Implementation of Mutual Exclusion
Attempt 4
var flag array0..1 of Boolean / initialize
both to false / / shared /

• Process 0
• flag0 true
• while (flag1) do
• flag0 false
• ltdelay for short timegt
• flag0 true
• ltcritical sectiongt
• flag0 false

Process 1 flag1 true while (flag0) do
flag1 false ltdelay for short
timegt flag1 true ltcritical
sectiongt flag1 false
mutual exclusion? progress?
11
Dekkers Algorithm
/ shared variables/ var flag array0..1 of
Boolean / initially false / turn 0..1
/

• Process 0
• flag0 true
• while flag1 do
• if turn1 then
• flag0 false
• while turn1 do
• /nothing/
• flag0 true
• //end if
• //end while
• ltcritical sectiongt
• turn 1
• flag0 false

Process 1 flag1 true while flag0
do if turn0 then flag1 false while
turn0 do /nothing/ flag1
true ltcritical sectiongt turn
0 flag1 false
It has a name, it must be correct!
12
Proof Dekkers Algorithm Enforces Mutual
Exclusion

• What do we want to prove?
• Both Process 0 and Process 1 cannot be in their
• critical sections at the same time.
• What strategy can we use?
• Lets try proof by contradiction.
• How should we go about doing that?
• Assume that both are in their critical sections.
• Derive a logical inconsistency.

13
Proof

• Assume that both Processes 0 1 are in their
  critical section.
• Before entering, each had to execute
• set its flag to true, then
• line 2 of Dekkers while flag1 do ....
• Assembler translation of these would consist of
  3 or less instructions
• Store true into my flag
• Load others flag value into a register
• Branch to critical section if register value
  is false
• One of the processes had to execute the second
  inst. after the other did.
• WLOG we can assume that Process 0 executed the
  second of these last So process 1 had already
  executed the first 2 of these by this time So,
  processs 1 flag was True when process 0 executed
  it
• But, process 0 found process 1s flag to be
  False
• Since process 1s flag cannot be both true
  and false (a logical contradiction), we are
  done.

14
Note about turn

• Note We did not use turn in our proofs.
• Is turn really necessary to assure that mutual
  exclusion is enforced?
• Reconsider Attempt 3 and Attempt 4.
• They did not use turn.
• Did they guarantee that mutual exclusion was
  enforced?
• So, what was wrong with them?
• And, what is the purpose of turn?

15
Petersons Algorithm
/ shared variables/ var flag array0..1 of
Boolean / initially false / turn 0..1 /
wlog, initially 1 /

• Process 0
• flag0 true
• turn 1
• while flag1 and (turn1) do
• /nothing/
• ltcritical sectiongt
• flag0 false

Process 1 flag1 true turn 0 while
flag0 and (turn0) do /nothing/ ltcritic
al sectiongt flag1 false
16
More On Petersons Algorithm

• Logic behind it
• Say Im interested
• If you see anyone else is interested, say your
  turn
• Someone is the last one to say your turn --
  they wait until other finishes, then they get
  the lock.
• Simpler than Dekkers Algorithm
• Generalizable to more than 2 processes
• Think of a tournament. If you face no one, you
  advance to the next tier. Single turn bit
  needed for each tier.

17
Homework Problem (show that this is an incorrect
solution )
/ shared variables/ var blocked array0..1 of
Boolean / initially false / turn 0..1 /
wlog, initially 1 /

• Process 0
• blocked0 true
• while(turn ! 0) do
• while(blocked1 do
• nothing
• turn 0
• ltcritical sectiongt
• blocked0 false

Process 1 blocked1 true while(turn ! 1) do
while(blocked0 do nothing turn
1 ltcritical sectiongt blocked1 false
HOMEWORK Problem 5.5, pages 245-246. HOMEWORK
Problem 5.5, pages 245-246. Note This algorithm
was published in Communications of the ACM
18
Problem with software approaches?

• BUSY Waiting
• Complicated
• CAN HARDWARE HELP?

19
Hardware Assisted Locks

• Disabling Interrupts
• Not acceptable
• Infinite loops or other run-away code
• No concurrency permitted (even those processes
  who dont want to enter a critical section may
  not execute)
• Use of special atomic instructions
• Atomic test-and-set instruction
• function testset (var i integer) Boolean
• if (i0)
• I 1
• return(true)
• else return(false)
• or, Atomic Exchange instruction.
• or, Atomic Increment instruction.

20
Using Atomic test-and-set

• Initially, lock is declared to be a shared
  integer and it is initialized to 0.
• Repeat
• / nothing /
• until testset(lock)
• ltcritical sectiongt
• lock 0
• Note, this solution works for any number of
  processes.

21
Atomic Exchange Instruction

• procedure exchange (var r register var m
  memory)
• var temp
• begin
• temp m
• m r
• r temp
• end

22
Using Atomic Exchange

• Assume lock is a shared integer variable (memory
  location) initialized to 0.
• R4 1
• repeat
• exchange(R4, lock)
• until (R4 0)
• ltcritical sectiongt
• R4 0 / in case it was changed during CS /
• exchange(R4, lock)
• Does this solution work for more than 2
  processes?

23
Mutual Exclusion Machine Instructions

• One machine instruction is used to update a
  memory location so other instructions cannot
  interfere
• Simple, easy to verify
• This can be used for single and multiple
  processors
• It can be used for multiple critical sections

24
Mutual Exclusion Machine Instructions

• Disadvantages
• Busy-waiting consumes processor time
• Starvation is possible when a process leaves a
  critical section and more than one process is
  waiting. Who is next?
• Deadlock
• If a low priority process has the critical region
  and a higher priority process needs, the higher
  priority process will obtain the processor to
  wait for the critical region

25
Semaphores

• Special variable called a semaphore is used for
  signaling
• If a process is waiting for a signal, it is
  suspended until that signal is sent
• Wait and signal operations cannot be interrupted
• Queue is used to hold processes waiting on the
  semaphore

26
Semaphore definition
/
Type semaphore record count integer queue
list of process var s sempaphore

• wait(s)
• s.count s.count -1
• if (s.count lt 0)
• place this process in s.queue
• block this process

signal(s) s.count s.count 1 if (s.count lt
0) remove a process P from s.queue place
process P on ready list
27
Producer/Consumer Problem or bounded buffer
problem

• One or more producers are generating date and
  placing these in a buffer
• A single consumer is taking items out of the
  buffer one at time
• Only one producer or consumer may access the
  buffer at any one time
• Two semaphores are used
• one to represent the amount of items in the
  buffer
• one to signal that it is all right to use the
  buffer

28
Producer Function

• producer
• repeat
• produce item v
• bin v
• in in 1
• forever

29
Consumer Function

• consumer
• repeat
• while in lt out do nothing
• w bout
• out out 1
• consume item w
• forever

30
Producer with Circular Buffer

• producer
• repeat
• produce item v
• while ( (in 1) mod n out) do nothing
• bin v
• in (in 1) mod n
• forever

31
Consumer with Circular Buffer

• consumer
• repeat
• while in out do nothing
• w bout
• out (out 1) mod n
• consume item w
• forever

32
Bounded Buffer Producer Consumer
/ shared variables/ semaphore s (1), n (0),
e //(sizeOfBuffer)

• Process Producer
• while(true)
• produce
• wait(e)
• wait(s)
• append
• signal(s)
• signal(n)

Process consumer while(true) wait(n) wait(s)
take signal(s) signal(n) consume
33
Monitors Another Language Mechanism

• Avoids busy wait problem
• Protects Objects
• Removes need for some nested locking
• Monitor Stack
• guarded Procedure Push
• guarded Procedure Pop
• Procedure IsFull
• end Monitor Stack

34
Monitors Conceptually
Condition Queues

Enter
Exit
Urgent Queue
35
Monitor Example

• Monitor Stack
• guarded Procedure Push(value)
• cwait NotFull
• Stack.valuesStack.top value
• Stack.top
• csignal NotEmpty
• end Push

36
Windows Critical Section construct

• Critical sections allow only one thread at a time
  to gain access to a region of data.
• Threads must belong to a single process.
• Bound the critical region of code with
• EnterCriticalSection(ptrToCS)
• Do something to shared resource
• LeaveCriticalSection(ptrToCS)
• Once CS is occupied, all other threads
  requesting access will be put to sleep. When CS
  is free, the system wakes up one thread (the rest
  continue to sleep)

37
Readers/Writers Problem

• Any number of readers may simultaneously read the
  file
• Only one writer at a time may write to the file
• If a writer is writing to the file, no reader may
  read it

38
Readers-Writers Problem

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

39
Readers-Writers Problem (Cont.)

• Reader process
• wait(mutex)
• readcount readcount 1
• if readcount 1 then wait(wrt)
• signal(mutex)
• reading is performed
• wait(mutex)
• readcount readcount 1
• if readcount 0 then signal(wrt)
• signal(mutex)