2. OBJECTIVES
• To present both software and hardware
solutions of the critical-section problem
• To introduce the critical-section problem,
whose solutions can be used to ensure the
consistency of shared data
• To introduce the concept of an atomic
transaction and describe mechanisms to
ensure atomicity
SYNCHRONIZATION 2 JGEC-IT
3. PROCESS SYNCHRONIZATION
• Background
• The Critical-Section Problem
• Peterson’s Solution
• Semaphores
• Classic Problems of Synchronization
• Monitors
• Synchronization Examples
• Atomic Transactions
SYNCHRONIZATION 3 JGEC-IT
4. 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 count that keeps
track of the number of full buffers. Initially, count is set
to 0. It is incremented by the producer after it
produces a new buffer and is decremented by the
consumer after it consumes a buffer.
SYNCHRONIZATION 4 JGEC-IT
5. Producer
while (true) {
/* produce an item and put in nextProduced */
while (count == BUFFER_SIZE)
; // do nothing
buffer [in] = nextProduced;
in = (in + 1) % BUFFER_SIZE;
count++;
}
SYNCHRONIZATION 5 JGEC-IT
6. Consumer
while (true) {
while (count == 0)
; // do nothing
/* consume the item in nextConsumed */
nextConsumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
count--;
}
SYNCHRONIZATION 6 JGEC-IT
8. Critical Section Problem
• Consider system of n processes { P0 , P1 , …, Pn-1 }
• Each process has a critical section segment of code
– Process may be changing common variables, updating table,
writing file, etc.
– When one process is in its critical section, no other may be
executing in its critical section
• Critical-section problem is to design a protocol to solve this
• Each process must ask permission to enter its critical section in
entry section, may follow critical section with exit section, the
remaining code is in its remainder section
SYNCHRONIZATION 8 JGEC-IT
12. Solution to Critical-Section Problem
Mutual Exclusion - If process Pi is executing in its critical section, then no
other processes can be executing in their critical sections
2. Progress - If no process is executing in its critical section and there exist
some processes that wish to enter their critical section, then the
selection of the processes that will enter the critical section next cannot
be postponed indefinitely
SYNCHRONIZATION 12 JGEC-IT
14. Solution to Critical-Section Problem(cntd.)
3. Bounded Waiting - A bound must exist on the number of times that other
processes are allowed to enter their critical sections after a process has
made a request to enter its critical section and before that request is
granted
Assume that each process executes at a nonzero speed
No assumption concerning relative speed of the N processes
SYNCHRONIZATION 14 JGEC-IT
16. Peterson’s Solution
• Two process solution
• Assume that the LOAD and STORE instructions are atomic; that is, cannot be
interrupted.
• The two processes share two variables:
– int turn;
– Boolean flag[2]
• The variable turn indicates whose turn it is to enter the critical section.
• The flag array is used to indicate if a process is ready to enter the critical section.
flag[i] = true implies that process Pi is ready!
SYNCHRONIZATION 16 JGEC-IT
17. Algorithm for Process Pi
do {
flag[i] = TRUE;
turn = j;
while (flag[j] && turn == j);
critical section
flag[i] = FALSE;
remainder section
} while (TRUE);
• Provable that
1. Mutual exclusion is preserved
2. Progress requirement is satisfied
3. Bounded-waiting requirement is met
SYNCHRONIZATION 17 JGEC-IT
19. Semaphore
• Two atomic operations
• Integer variable, with initial non-negative value
– wait
– signal (not the UNIX signal() call…)
– p & v (proberen & verhogen), up and down,
etc
• wait
– wait for semaphore to become positive,
then decrement by 1
• signal
– increment semaphore by 1
SYNCHRONIZATION 19 JGEC-IT
21. Mutual exclusion using semaphores
• Use wait and signal like lock and unlock
– bracket critical sections in the same manner
• Semaphore value should never be greater than 1
– This is a binary semaphore
• Depends on correct order of calls by programmer
• All mutex problems apply (deadlock…)
SYNCHRONIZATION 21 JGEC-IT
23. Semaphore Usage
• Counting semaphore – integer value can range over an unrestricted
domain
• Binary semaphore – integer value can range only between 0 and 1
– Then equivalent to a mutex lock
• Can solve various synchronization problems
• Consider P1 and P2 that require S1 to happen before S2
P1:
S1;
signal(synch); //sync++ has added one
resource
P2:
wait(synch); //executed only when
synch is > 0
S2;
SYNCHRONIZATION 23 JGEC-IT
24. Semaphore Implementation
• Must guarantee that no two processes can execute wait() and
signal() on the same semaphore at the same time
• Thus, implementation becomes the critical section problem, where
the wait and signal codes are placed in the critical section
– Could now have busy waiting in critical section implementation
• But implementation code is short
• Little busy waiting if critical section rarely occupied
• Note that applications may spend lots of time in critical sections and
therefore this is not a good solution
SYNCHRONIZATION 24 JGEC-IT
25. Semaphore Implementation with no Busy waiting
o With each semaphore there is an associated waiting queue. Each entry in
a waiting queue has two data items:
an integer value
a list of processes
Two operations:
– block – place a process into a waiting queue associated with the
semaphore.
– wakeup – changes the process from the waiting state to ready state
SYNCHRONIZATION 25 JGEC-IT
26. Semaphore Implementation with no Busy waiting (Cont.)
• Implementation of wait:
acquire () {
value--;
if (value < 0) {
add this process to list;
block(); }
}
• Implementation of signal:
release () {
value++;
if (value <= 0) {
remove a process P from list;
wakeup(P); }
}
SYNCHRONIZATION 26 JGEC-IT
27. Classical Problems of Synchronization
• Bounded-Buffer Problem
• Readers and Writers Problem
• Dining-Philosophers Problem
SYNCHRONIZATION 27 JGEC-IT
28. Bounded-Buffer Problem
• N buffers, each can hold one item
• Semaphore mutex initialized to the value 1
• Semaphore full initialized to the value 0
• Semaphore empty initialized to the value N.
SYNCHRONIZATION 28 JGEC-IT
30. Bounded Buffer Problem (Cont.)
• The structure of the producer process
do {
// produce an item in nextp
wait (empty);
wait (mutex);
// add the item to the buffer
signal (mutex);
signal (full);
} while (TRUE);
SYNCHRONIZATION 30 JGEC-IT
31. Bounded Buffer Problem (Cont.)
• The structure of the consumer process
do {
wait (full);
wait (mutex);
// remove an item from buffer to
nextc
signal (mutex);
signal (empty);
// consume the item in nextc
} while (TRUE);
SYNCHRONIZATION 31 JGEC-IT
34. Readers-Writers Problem
• A data set is shared among a number of concurrent processes.
– Readers – only read the data set; they do not perform any updates
– Writers – can both read and write
• Problem – allow multiple readers to read at the same time. Only one
single writer can access the shared data at the same time.
• Shared Data
– Data set
– Semaphore mutex initialized to 1 (controls access to readcount)
– Semaphore wrt initialized to 1 (writer access)
– Integer readcount initialized to 0 (how many processes are reading
object)
SYNCHRONIZATION 34 JGEC-IT
35. Readers-Writers Problem (Cont.)
• The structure of a writer process
do {
wait (wrt) ;
// writing is performed
signal (wrt) ;
} while (TRUE);
SYNCHRONIZATION 35 JGEC-IT
36. Readers-Writers Problem (Cont.)
• The structure of a reader process
do {
wait (mutex) ;
readcount ++ ;
if (readcount == 1)
wait (wrt) ;
signal (mutex)
// reading is performed
wait (mutex) ;
readcount - - ;
if (readcount == 0)
signal (wrt) ;
signal (mutex) ;
} while (TRUE);
SYNCHRONIZATION 36 JGEC-IT
39. 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
S.acquire(); Q.acquire();
Q.acquire(); S.acquire();
. .
. .
. .
S.release(); Q.release();
Q.release(); S.release();
SYNCHRONIZATION 39 JGEC-IT
40. Deadlock and Starvation(cntd.)
• P0 executes S.acquire() and then P1 executes
Q.acquire().
• When P0 executes Q.acquire(), it must wait until
P1 executes Q.release().
• Similarly, when P1 execute S.acquire(), it must
wait until P0 executes S.release()
• Since these signal operations cannot be executed,
P0 and P1 are deadlocked.
SYNCHRONIZATION 40 JGEC-IT
43. Deadlock and Starvation(cntd.)
• Starvation – indefinite blocking :
• A process may never be removed from the semaphore queue in which it is
suspended.
SYNCHRONIZATION 43 JGEC-IT
45. Dining-Philosophers Problem (Cont.)
• The structure of Philosopher i:
do {
wait ( chopstick[i] );
wait ( chopStick[ (i + 1) % 5] );
// eat
signal ( chopstick[i] );
signal (chopstick[ (i + 1) % 5] );
// think
} while (TRUE);
What is the problem with the above?
SYNCHRONIZATION 45 JGEC-IT
47. The Structure of Philosopher i
Philosopher i
while ( true ) {
// get left chopstick
chopStick[i].acquire();
// get right chopstick
chopStick[(i + 1) % 5].acquire();
eating();
//return left chopstick
chopStick[i].release( );
// return right chopstick
chopStick[(i + 1) % 5].release( );
thinking();
}
SYNCHRONIZATION 47 JGEC-IT
49. Possible Remedies
• Placing restrictions on the philosophers
– Allow at most four philosophers to be sitting
simultaneously at the table
– Allow a philosopher to pick up her chopsticks only
if both are available
– An odd philosopher picks up first her left
chopsticks and even philosopher picks up her right
chopstick and then right
SYNCHRONIZATION 49 JGEC-IT
51. Monitors
SYNCHRONIZATION 51 JGEC-IT
A high-level abstraction that provides a convenient and
effective mechanism for process synchronization
Only one process may be active within the monitor at a time
monitor monitor-name
// shared variable declarations
procedure P1 (…) { …. }
…
procedure Pn (…) {……}
Initialization code ( ….) { … }
…
}
}
