ITEC 502 ??? ??? ? ??

1
ITEC 502 ??? ??? ? ??

• Chapter 3-1
• Process Synchronization
• Mi-Jung Choi
• mjchoi_at_postech.ac.kr
• DPNM Lab. Dept. of CSE, POSTECH

2
Contents

1. Race Conditions
2. Critical Regions
3. Mutual Exclusion with Busy Waiting
4. Sleep and Wakeup
5. Semaphores
6. Mutexes

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
Interprocess Communication

• IPC for short
• Race conditions
• may occur in a system where multiple processes
  work together
• situations where the final outcome depends on who
  runs precisely when
• Example spool system

5
Race Condition (1)

• 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?

6
Race Condition (2)

• 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

7
Critical-Region (CR) Problem

• A system consisting of n processes P0, P1, ,
  Pn-1
• Each process has a segment of code, called a
  critical region, 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 region at the same
  time
• Solution to the critical-region problem
• To design a protocol that the processes can use
  to cooperate
• Each process must request permission to enter
  its CR
• The section of code implementing this request is
  the entry section
• The CR may be followed by an exit section
• The remaining code is the remainder section

8
Critical-Region Problem

• The general structure of a typical process Pi

9
Critical Regions (1)

• Mutual exclusion to avoid race conditions
• Four conditions to provide mutual exclusion
• C1 No two processes simultaneously in CR
• C2 No assumptions about speeds or numbers of
  CPUs
• C3 No process outside its CR may block another
  process
• C4 No process should have to wait forever to
  enter its CR

10
Critical Regions (2)

• Mutual exclusion using critical regions
• - This is what we want

11
Solution to Critical-Region Problem

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

12
Petersons Solution for critical region 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 region
• The flag array is used to indicate if a process
  is ready to enter the critical region
• flagi true implies that process Pi is ready!

13
Algorithm for Process Pi

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

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

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

15
Mutual Exclusion with Busy Waiting (1)

• Disabling interrupts
• disable interrupts while a process in CR
• what happens if there is another CPU?? ? violates
  C2!
• Lock variables
• shared (lock) variable, initially 0
• set it to 1 to enter and to 0 to leave CR
• do not solve the problem at all!
• Strict alternation
• processes A and B enter CR alternatively
• violates C3

16
Mutual Exclusion with Busy Waiting (2)

• Peterson's solution for achieving mutual exclusion

17
Mutual Exclusion with Busy Waiting (3)
TSL RX, LOCK (1) copy value at LOCK to RX
(2) store non-zero at LOCK these two steps
are indivisible!

• Entering and leaving a critical region using the
  TSL instruction

18
Sleep and Wakeup (1)

• Both Petersons and TSL solutions are correct,
  but
• they require busy waiting ? waste CPU cycles
• also, the priority inversion problem may occur!
• ? Blocking sys. calls preferable to busy-waiting
• Sleep()
• block itself
• Wakeup(pid)
• unblock another process pid

19
Sleep and Wakeup (2)

• Producer-consumer problem with fatal race
  condition

20
Semaphore (1)

• The various hardware-based solutions to the
  critical region problem
• 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 down() and
  up()
• The modification of the semaphore is atomic
• When one process modifies the semaphore value, no
  other process can simultaneously modify that same
  semaphore value
• less complicated to use

21
Semaphore (2)

• Semaphore Alphabet

22
Semaphores (3)

• Problem with sleep/wakeup
• wakeup signal can be lost ? wakeup waiting bit
• what if there are many processes involved??? we
  need a counter for wakeups!? motivation of
  semaphores
• Semaphores
• integer variables with atomic operations down()
  and up()
• down(s)
• If (s 0) then sleep()
• else s s-1
• up(s)
• s s1
• if there is another process sleeping on s, wake
  it up

23
Usage of Semaphore (1)

• Binary semaphore
• Integer value can range only between 0 and 1
• Which is refer to as mutex locks
• Binary semaphore for solving the critical-region
  problem for multiple processes
• n processes share a semaphore, mutex
• mutex is initialized to 1
• The structure of a process Pi

do down (mutex) CRITICAL Region
up (mutex) REMAINDER Section while
(TRUE)
24
Usage of Semaphore (2) - Binary Semaphore

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

25
Semaphores (4)

• The producer-consumer problem using semaphores

26
Semaphores (5)
void producer(void) int item while
(TRUE) item produce_item()
down(empty) down(mutex)
insert_item(item) up(mutex)
up(full)
void consumer(void) int item while
(TRUE) down(full) down(mutex)
remove_item(item) up(mutex)
up(empty) consume_item(item)
define N 100 typedef int semaphore semaphore
mutex 1 semaphore empty N semaphore full
0

• The producer-consumer problem using semaphores

27
Mutexes

• Implementation of mutex_lock and mutex_unlock
• ? Can be easily implemented in user space with
  the help of TSL

28
Summary

• Cooperating processes that share data have
  critical region of code each of which is in use
  by only one process at a time
• Three requirements for critical region problem
• Mutual Exclusion, Progress, Bounded Waiting
• The main disadvantage of these solution is that
  they all require busy waiting. Semaphore overcome
  this difficulty
• In the next class
• 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

29
Review

1. Race Conditions
2. Critical Regions
3. Mutual Exclusion with Busy Waiting
4. Sleep and Wakeup
5. Semaphores
6. Mutexes