process synchronization - fau college of engineeringtami/cop4610m8slides.pdf · operating systems...
TRANSCRIPT
MODULE 8 – PROCESS SYNCHRONIZATION
The Critical-Section Problem Peterson’s Solution Synchronization hardware
2Tami Sorgente
PROCESS SYCHRONIZATION
Processes can execute concurrentlyMay be interrupted at any time, partially completing execution
Concurrent access to shared data may result in data inconsistency
Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes
3Tami Sorgente
PRODUCER/ CONSUMER (BOUNDED BUFFER)
PRODUCER:
while (true) {/* produce an item in next produced */
while (counter = = BUFFER_SIZE) ;
/* do nothing */
buffer[in] = next_produced;
in = (in + 1) % BUFFER_SIZE;
counter++;
}
CONSUMER:
while (true) {
while (counter = = 0);
/* do nothing */
next_consumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
counter--;
/* consume the item in next consumed */
}
4Tami Sorgente
RACE CONDITION
Several processes access and manipulate the same data outcome of execution depends on the particular order
Producer/consumer :
counter++ could be implemented as
register1 = counterregister1 = register1 + 1counter = register1
counter-- could be implemented as
register2 = counterregister2 = register2 - 1counter = register2
Consider this execution interleaving with “count = 5” initially:
S0: producer execute register1 = counter {register1 = 5}S1: producer execute register1 = register1 + 1 {register1 = 6} S2: consumer execute register2 = counter {register2 = 5} S3: consumer execute register2 = register2 – 1 {register2 = 4} S4: producer execute counter = register1 {counter = 6 } S5: consumer execute counter = register2 {counter = 4}
5Tami Sorgente
CRITICAL SECTION PROBLEM
Each process has critical section segment of code
o Process may be changing common variables, updating table, writing file, etc
o When one process in critical section, no other may be in its critical section
Critical section problem
Each process must ask permission to enter critical section in entry section, may follow critical section with exit section
6Tami Sorgente
CRITCAL SECTION
A TYPICAL Process Pi:
7
Entry Section
Exit Section
CS (Critical Section)
do
{
remainder
section
} while(true);
Shared data
Protocol for
ME
Different
Approaches
for
Entry and exit
Ask for
permission
Tami Sorgente
SOLUTION TO CRITICAL SECTION PROBLEM
Mutual Exclusion (ME)
Progress processes NOT executing in the remainder section can participate in decision of who goes in CS, cannot be postponed indefinitely
Bounded waiting – no process should wait for a very long time (fairness) not cause deadlock
8Tami Sorgente
PETERSON’S SOLUTIONBoolean turn = 0;
Boolean flag [2] = {0};
P1 - flag1 turn = 0 //P1
P2 – flag2 turn = 1 //P2
9
flag1 = true;
turn = P2;
while(flag2 && turn==P2);
flag1= false;
CS (Critical Section)
do{
remainder section
} while(true);
Set P1 flag to True
ENTRY
EXITWhen P1 exits
set flag to false
If P2 flag is true and
turn is P2 - wait
Set turn to P2
Tami Sorgente
PETERSON’S SOLUTION
Peterson’s solution (2 processes) solves 3 conditions:
Mutual exclusion –If you are interested and it is your turn – I let you go
Progress – both conditions must be true for process to get stuck in while loop
Bounded waiting – Eventual value of turn decides who will enter
10Tami Sorgente
SYNCHRONIZATION HARDWARE
Many systems provide hardware support for implementing the critical section code.
Idea of lockingo Protecting critical regions via locks
Uniprocessors – could disable interruptso Currently running code would execute without
preemptiono Generally too inefficient on multiprocessor systems
Modern machines provide special atomic hardware instructions
Atomic = non-interruptibleo Either test memory word and set valueo Or swap contents of two memory words
11Tami Sorgente
SOLUTION TO CRITICAL-SECTION
PROBLEM USING LOCKS
do {
acquire lock
critical section
release lock
remainder section
} while (TRUE);
12Tami Sorgente
LOCKS
• Protect a critical section by first acquire()a lock then release() the lock
o Boolean variable indicating if lock is available or not
• Calls to acquire() and release() must be atomic
o Usually implemented via hardware atomic instructions
• This solution requires busy waiting
o This lock therefore called a spinlock
13Tami Sorgente