Concurrency: Mutual Exclusion and Synchronization

1
Concurrency Mutual Exclusion and Synchronization

• Concurrency 1
• Concurrency and Mutual Exclusion

2
Relevant Definitions

• Multiprogramming multiple processes on a single
  processor
• Multiprocessing multiple processes on multiple
  processors
• Distributed processing multiple processes on
  multiple independent computer systems.

3
Principles of Concurrency

• Concurrent processes (or threads) execute during
  a shared time interval and may need to share
  resources files, data structures,
• Concurrent processes are asynchronous the order
  of interleaved or overlapped instructions cant
  be predicted, and may vary from one time to the
  next

4
Process Isolation Shared Memory

• Normally, processes run in a protected address
  space, as we have seen.
• Sometimes processes need to share data by reading
  and writing to the same memory locations. The OS
  provides system calls to make this possible.
• Threads in a single process may share information
  by reading/writing shared memory in the process.

5
Problems

• If there is no controlled access to shared data,
  processes or threads may get an inconsistent view
  of this data
• The result of concurrent execution will depend on
  the order in which instructions are interleaved.
• Errors are timing dependent and usually not
  reproducible.

6
A Simple Example (p.204-205)

• Assume P1 and P2 are executing this code segment
  and have access to the same variable a
• Processes can be preempted at any time.
• Assume P1 is preempted after the input statement,
  and P2 then executes entirely
• The character echoed by P1 will be the one read
  by P2 !!
• Similar problems arise if P1 and P2 run
  concurrently on an SMP

static char a void echo() cin gtgt a
cout ltlt a
7
Whats the Problem?

• This is an example of a race condition the
  situation that exists when two or more processes
  are changing shared data and the final result
  depends on timing.
• Individual processes (threads) execute
  sequentially in isolation, but concurrency causes
  them to interact.
• We need to prevent concurrent execution by
  processes when they are changing the same data.
  We need to enforce mutual exclusion.

8
The Critical Section Problem

• When a process executes code that manipulates
  shared data (or resources), we say that the
  process is in its critical section (CS) for that
  shared data
• We must enforce mutual exclusion on the execution
  of critical sections.
• Only one process at a time can be in its CS (for
  that shared data or resource).

9
The Critical Section Problem

• Enforcing mutual exclusion guarantees that
  related CSs will be executed serially instead of
  concurrently.
• The critical section problem is how to provide
  mechanisms to enforce mutual exclusion so the
  actions of concurrent processes wont depend on
  the order in which their instructions are
  interleaved

10
The Critical Section Problem

• Processes/threads must request permission to
  enter a CS, signal when they leave CS.
• Program structure
• entry section requests entry to CS
• exit section notifies that CS is completed
• remainder section (RS) code that does not
  involve shared data and resources.
• The CS problem exists on multiprocessors as well
  as on uniprocessors.

11
Process Interaction (p. 207)

• Concurrent processes may be independent (unaware
  of each other) but in competition for shared
  resources e.g., printer. The OS must manage this
  type of interaction.
• Other processes may be aware of each other,
  indirectly or directly. They must cooperate to
  use shared resources. OS may provide the
  mechanisms.

12
Concurrency Control Problems

• Mutual Exclusion and Data Coherence
• Deadlock
• Starvation
• See Table 5.2 (p. 208)

13
Mutual Exclusion and Data Coherence

• Mutual Exclusion ensures data coherence if
  properly used.
• Critical Resource (CR) - a shared resource such
  as a variable, file, or device
• Data Coherence
• The final value or state of a CR shared by
  concurrently executing processes is the same as
  the final value or state would be if each process
  executed serially, in some order.

14
Deadlock and Starvation

• Deadlock two or more processes are blocked
  permanently because each is waiting for a
  resource held in a mutually exclusive manner by
  one of the others.
• Starvation a process is repeatedly denied access
  to some resource which is protected by mutual
  exclusion, even though the resource periodically
  becomes available.

15
Requirements for Mutual Exclusion

• Mutual Exclusion At most one process can be in
  its CS.
• Non-interference A process that halts in its
  remainder section must not interfere with other
  processes.
• Progress If no process is executing in its CS a
  process that wishes to enter its CS must be
  allowed to do so at once.

16
Requirements for Mutual Exclusion

• Bounded waiting when a process requests access
  to its CS it cannot be delayed indefinitely (no
  deadlock, no starvation)
• No assumptions can be made about relative process
  speeds or number of processors
• A process remains in its critical section a
  finite amount of time.

17
Solutions to the Mutual Exclusion Problem

• Four levels of solutions
• software implemented by individual cooperating
  processes without additional support from
  hardware, language, or OS
• hardware require special instructions or other
  hardware features
• OS special system calls supported by kernel
• Language features provided by programming
  languages

18
Software Solutions(See Appendix A.1 p. 730)

• All solutions are based on a fundamental
  characteristic of computer hardware the
  indivisible load and store operations.
• If two accesses to the same memory location occur
  at the same time, the hardware will serialize the
  accesses.
• This feature mediates between CPU and DMA device,
  and between two processors on an SMP

19
Software Solutions Good Bad

• First consider 2 - process solutions (p.731)
• Algorithm 1, 2, and 3 are incorrect
• Algorithm 4 is almost correct
• Petersons algorithm (Fig. A.3 p.736) is
  correct
• Notation
• Call the two processes P0 and P1
• When the notation Pi, Pj is used, assume (i ! j)

20
First Attempt

• Turn is either 0 or 1 before the processes begin
  to run.
• Pi may enter critical section when turn i (e.g.
  P0 enters if i0)
• Mutual exclusion satisfied
• P0 will hang at the while loop as long as turn
  1, and vice versa
• Progress requirement not satisfied
• Strict alternation
• P0 enters CS first
• P0 exits CS, sets turn 1
• P0 executes short RS
• P0 wants to enter CS again
• P1 must enter CS first to set the turn variable
  back to 0.

Process P0 repeat while(turn!0) CS
turn1 RS forever
Process P1 repeat while(turn!1) CS
turn0 RS forever
21
Second Attempt

• Flag stores a Boolean variable for each
  process
• P0 tests flag1 while it is true, continue to
  test (busy-wait)
• When flag1 is false P0 signals that it wants to
  enter its CS by setting flag 0 true
• Mutual Exclusion is not satisfied
• P0 tests flag1 and finds it false
• P1 tests flag0 and finds it false
• P0 sets flag0 true - too late!
• P1 sets flag1 true - too late!
• P0 and P1 both have permission to execute the
  critical section

Process P0 repeat while(flag1)
flag0true CS flag0false
RS forever
Process P1 repeat while(flag0)
flag1true CS flag1false
RS forever
22
Third Attempt

• Try to fix the problem by setting your own flag
  before testing the other flag.
• Assume P0 sets flag 0 true
• Mutual Exclusion is satisfied
• P1 will not enter CS because flag 0 is set to
  true
• But bounded waiting requirement is not
  satisfied
• P0 sets flag 0 true
• P1 sets flag 1 true
• P0 tests flag1 - its true!
• P1 tests flag0 - true also!
• Both processes will loop forever deadlock

Process P0 repeat flag0true
while(flag1) CS flag0false
RS forever
Process P1 repeat flag1true
while(flag0) CS flag1false
RS forever
23
Fourth Attempt

• Try to fix the problem by turning off your flag
  for a random delay.
• Mutual exclusion is satisfied, but waiting may
  not be bounded
• P0 sets flag 0 true
• P1 sets flag 1 true
• P0 tests flag1 - its true!
• P1 tests flag0 - true also!
• P0 sets flag0 false
• P1 sets flag1 false
• P0 sets flag0 true
• P1 sets flag1 true
• ad infinitum
• Both processes could loop forever livelock

Process P0 flag0true while(flag1)(
flag0false / delay / flag0
true CS flag0 false
Process P1 flag1true while(flag0)(
flag1false / delay / flag1
true CS flag1 false
24
Petersons Algorithm

• Initialization
• flag0 flag1 false
• turn 0 or 1
• Willingness to enter CS specified by flagi
  true
• If both processes want to access the CS at the
  same time, the variable turn will decide it will
  be either 0 or 1 never both.
• Exit section specifies that Pi is no longer in CS

Process P0 repeat flag0 true turn 1
while(flag1 turn1) CS
flag0false RS forever
Process P1 repeat flag1 true turn 0
while(flag0 turn0) CS
flag1false RS forever
25
Correct Software Solutions

• Dekkers algorithm was the first correct solution
  proposed, but is complex.
• Petersons algorithm is a simpler implementation
  of the same general idea.
• L. Lamports Bakery Algorithm is an n-process
  solution which uses the take-a-number concept
  to resolve conflicts when multiple processes want
  to enter CS.

26
Performance of Software Solutions

• If all criteria (ME, progress, bounded waiting,
  etc.) are satisfied, then a valid solution will
  protect against the failure of a process in its
  remainder section (RS)
• No solution can provide robustness against a
  process failing in its critical section (CS)
• A process Pi that fails in its CS is equivalent
  to a process with an infinitely long CS
• Software solutions use busy-waiting.

27
Hardware Solutions 5.2

• Disable interrupts
• Test-and-set instruction
• Exchange instruction

28
Disable Interrupts

• On a uniprocessor
• mutual exclusion guaranteed, since nothing can
  interrupt the running process.
• But OS has no control if user program decides
  not to enable the interrupts
• OS cannot preempt process
• Multiprogramming is lost
• On a multiprocessor
• mutual exclusion is not preserved

Process Pi repeat disable interrupts
critical section enable interrupts remainder
section forever
29
Special Machine Instruction - Test-and-Set

• Test-and-set is a hardware instruction that tests
  the value of its argument i and returns true if i
  0, false if i 1. In every case, i 1 after
  the instruction completes.
• The key point is that this all happens in a
  single machine instruction there is no way to
  separate the test operation from the set
  operation.

30
The test-and-set instruction

• Using test-and-set
• shared variable i is initialized to 0
• The first Pi to find i0 gets to enter CS

• C description of testset

bool atomic testset(int i) if (i0)
i1 return true else return
false // atomic means the entire
function must execute atomically without
interruption //
Process Pi repeat repeat until
testset(i) CS i0 RS forever
31
The Problem with test-and-set

• Mutual exclusion is preserved if Pi enters CS, i
  is set to 1, so no other process can enter.
• Problem still uses busy waiting (constant
  looping)
• When a process exits CS, the selection of the
  next process to enter the CS is unpredictable, so
  the bounded wait requirement is violated and
  starvation is possible.

32
The Exchange Instruction

• Some processors (i.e. Pentium) provide an atomic
  exchange instruction (xchg(a,b) ) that swaps the
  contents of a and b.
• But xchg(a,b) suffers from the same drawbacks as
  test-and-set busy-wait, possibility of
  starvation, and deadlock due to priority
  inversion.

33
Advantages of Machine Instruction Approach

• Test-and-set, exchange have drawbacks, as noted,
  but they also have advantages
• will work for any number of processes
• will work on a uniprocessor or a multiprocessor
• simple to implement

34
Summary of Process Synchronization

• Cooperating concurrent processes are processes
  that can affect each other by modifying shared
  data or resources.
• Atomic actions are indivisible. In hardware,
  loads and stores are indivisible. Complex atomic
  machine instructions such as test-and-set may
  also be provided.
• On a uniprocessor, a process switch can occur
  between any two atomic actions thus the atomic
  actions of concurrent processes may be
  interleaved in any possible order.
• On a multiprocessor, atomic actions may be also
  be overlapped, (although memory accesses are
  still indivisible).

35
Summary of Process Synchronization

• Consequently, process results may be
  non-deterministic and non-repeatable if actions
  are not synchronized.
• Race Condition when two or more processes (or
  threads) modify a shared object concurrently and
  the results of the modification are different
  than they would have been if each process
  executed serially, in some order.
• Solutions to the mutual exclusion problem have
  the effect of making critical sections behave as
  if they are atomic operations. The objective is
  to avoid race conditions and ensure that process
  execution is deterministic.