Chapter 5: Process Synchronization: Silberschatz, Galvin and Gagne ©2013 Operating System Concepts - 9 Edition

Chapter 5: Process
Synchronization
Operating System Concepts – 9th Edition Silberschatz, Galvin and Gagne ©2013
Outline
 Introduction to Process Synchronization
 Critical Section Problem
 Solution to Critical Section Problem
Operating System Concepts – 9th Edition 5.2 Silberschatz, Galvin and Gagne ©2013
1. Introduction to Process
Synchronization
Introduction to Process Synchronization
 Modern OS support multiprogramming
 manage multiple processes
 improves the resource utilization
 multitasking makes the more interactive
 On single processor, processes can execute
concurrently
 multiple processes making progress
concurrently
Concurrent Execution
CPU Time-line
Srart
Process P1
Process P2
Process P3
P3
P2
P1
P2
P1
CPU
Independent vs. cooperating Processes
 Processes may be cooperating or independent
 Concurrent access to shared data may result in data
inconsistency
Producer/Consumer Problem
 Producer/ consumer processes
 Bounded buffer
 counter variable to keep track of
available buffer capacity
Producer/Consumer Problem…
counter=0
counter=1
counter=0
Producer Consumer
Produces Consumes
Data-Item Data-Item
Store Reduced Data-

Item in Buffer Get Data-Item from
Buffer
Produced
Buffer Data-Item
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 */
}
Concurrent Access to shared data…
 counter++ could be implemented as

register1 = counter
register1 = register1 + 1
counter = register1
 counter-- could be implemented as
register2 = counter
register2 = register2 – 1
counter = register2
 Consider the current value of “counter = 5”

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}
 Final Output is
 Consider this execution interleaving with “counter = 5”

initially:
S0: producer execute register1 = counter {register1 = 5}
S1: producer execute register1 = register1 + 1 {register1 = 6}
S2: producer execute counter = register1 {counter = 6 }
S3: consumer execute register2 = counter {register2 = 6}
S4: consumer execute register2 = register2 – 1 {register2 = 5}
S5: consumer execute counter = register2 {counter = 5}
 Final Output is
Need for Synchronization
 A situation where 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, is called a Race Condition
 To avoid such data inconsistencies, we need to ensure
that only one process at a time can be manipulating
the shared data
 To make such a guarantee, we require that the
processes be synchronized in some way
2. Critical Section Problem
Critical Section Problem
 Consider system of n processes {p0, p1, … pn-1}
 Each process has critical section segment of code
 Process may be changing common variables,
updating table, writing file, etc
 When one process in critical section, no other may be in
its critical section
 Critical section problem is to design protocol to solve
this
 Each process must ask permission to enter critical
section in entry section, may follow critical section with
exit section, then remainder section
Critical Section
 General structure of process Pi
P1 P2
#include<iostream> #include<iostream>
using namespace std; using namespace std;
int main() int main()
{ {
int local_variable1; int local_variable2;
int shared_variable; int shared_variable;
local_ variable2=shared_variable;
Entry code
shared_variable=local variable +9; Entry code
shared_variable=0;
Exit code
Exit code
}
}
Process Pi
Ask Permission
CS1
Leave Permission
Ask Permission
CS2
Leave Permission
Ask Permission
CS3
Leave Permission
A simple Solution to CS problem
For Process Pi
do {
Entry Section
while (turn == j);
Critical Code
critical section
Exit Code
turn = j;
remainder section
} while (true);
For Process Pj
do {
Entry Section
while (turn == i);
Critical Code
critical section
Exit Code
turn = i;
remainder section
} while (true);
Process Pi Turn= Process Pj
Pi starts Turn=i j Pi starts
CPUCPU
CPU
Switches
Switches to Pj
Switches
to Pj
to Pj
Pj Stops here
Pi Stops here CPU
CPU Switches
Switches to to
Pi Pi
Pj Stops here while(Turn=i);
while(Turn=j); while(Turn=i);
CS1
Pi Stops here
CS1
Exit Code
Pi Stops here
Solution to Critical-Section Problem
1. 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
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
Analysis of Simple Solution
1. Mutual Exclusion is satisfied
2. Progress is not satisfied
3. Bounded Waiting is satisfied
Analysis of Simple Solution
Process i Process j
Turn
Turn==i j
TurnTurn
=i =j
CS1 CS1 is executed
CS1 is executed CS1

CS2 CS2 is executed
CS3
Peterson’s Solution
 Good algorithmic description of solving the problem
 Two process solution
 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!
Algorithm for Process Pi
do {
flag[i] = true;
turn = j;
while (flag[j] && turn = = j);
critical section
flag[i] = false;
remainder section
} while (true);
Peterson’s Algorithm
Turn=i
Turn
Turn=j
i
Flag[i]=False
Flag[i]=True
Flag[j]=True
Flag[j]=False
Process Pi CPU Switches to Pi Process Pj
Pj starts
Pi starts
CPU Switches to Pj
Pi stops
Pj stops
CPU Switches to Pi
Flag[i]=True; Flag[j]=True;
Turn=j; Turn=i;
While(Flag[j] && Turn=j); While(Flag[i] && Turn=i);
CS1 Pi stops CS1
Exit Code
Pi stops
Analysis of Peterson’s Solution
Process Pi False
Flag[i]=False
Flag[i]= True Turn =
Turn = jij Flag[j]=False
Flag[j]=True Process Pj
Flag[i]=True;
Turn=j;
CS1 While(Flag[j] && Turn=j);
Flag[i]=False;
Flag[j]=True;
Turn=i;
Flag[i]=True; While(Flag[i] && Turn=i); CS1
Turn=j; Flag[j]=False;
Flag[i]=False;
Flag[i]=True;
Turn=j;
Flag[i]=False;
Peterson’s Solution (Cont.)
 Provable that the three CS requirement are met:
1. Mutual exclusion is preserved
2. Progress requirement is satisfied
3. Bounded-waiting requirement is met
Chapter 5: Process
Synchronization
(Lecture 2)
Outline
 Summary of the previous lecture

 Hardware Solutions to CS problem
 test_and_set instruction
 compare_swap_instruction
 Software based solutions to the CS problem

 mutex lock
 semaphore
 Some classical synchronization problems
Summary of the Previous Lecture
 Concurrent access to shared data can result

in data inconsistency
 Critical Section problem
 Basic structure of a solution to the critical
section problem
 necessary conditions
 Two process solution to CS problem
Synchronization Hardware
 Many systems provide hardware
support for implementing the critical
section code
 Uniprocessors – could disable
interrupts
 currently running code would execute without
preemption
 X86 architecture CLI and STI commands are
available to disable and enable interrupts
do {
disable Interrupt
disable Interrupt
critical section
enable
enable Interrupt
Interrupt
remainder section
} while (true);
Interrupt
Interrupt Flag=
Flag= 1
0
1
Process Pi Process Pj
Executes CLI command
CS1 CS1
Executes STI command
 Disabling interrupts can be used to solve
CS problem, however it can raise some
issues
 some device may need immediate
service
 performance can be reduced in
multiprocessor system
 clock synchronization can be an issue
 Modern machines provide special atomic
hardware instructions
Atomic = non-interruptible
 test_and_set
 compare_and_swap
Solution to Critical-section Problem Using Locks
do {
acquire lock
acquire lock
critical section
critical section
release lock
release lock
remainder section
remainder section
} while (TRUE);
test_and_set Instruction
boolean test_and_set (boolean *target )

*target
{
boolean
boolean rv
rv == *target;
*target;
*target == TRUE;
*target TRUE;
return rv:
return rv:
}
Solution using test_and_set()
 do {
while (test_and_set(&lock));
while (test_and_set(&lock)); /*do nothing */
/* critical
/* critical section
section*/*/
lock== false;
lock false;
/* remaindersection
/* remainder section
*/ */
} while (true);
Solution using test_and_set()
Process Pi Lock=False
Lock=True
Lock=False Process Pj
Pi starts Pj starts
CPU switches
CPUswitches to
switchesto Pj
toPjPi
CPU
While(test_and_set(&lock)); While(test_and_set(&lock));
Pi stops
CS CS
Lock=false
Pi stops
compare_and_swap Instruction
int compare _and_swap(int *value
*value,int expected
expected, int new_value
new_value )
{
int temp = *value;
if (*value == expected)
*value = new_value;
return temp;
}
Solution using compare_and_swap
 Shared integer “lock” initialized to 0;
 do {
while (compare_and_swap(&lock,
while 0,1)1)!=!=
(compare_and_swap(&lock, 0, 0);
0);
/* do nothing */
/*
/* critical section*/*/
critical section
lock
lock == 0;
0;
/* remainder
/* remaindersection
section*/ */
} while (true);
Solution using compare_and_swap()
Process Pi Lock=1
Lock=0
Lock=1 Process Pj
Pi starts Pj starts
While(compare_and_swap(&lock,
While(compare_and_swap(&lock,
0,1)!=0); CPUswitches
CPU switches toPj
to
0,1)!=0);
Pi
CS Pi stops
CS
Lock=0
Pi stops
Software Based Solutions
 Hardware based solutions are hardware

dependent
 generally inaccessible to application
programmer
 OS designers build software tools
 mutex lock
 semaphore
 n process solutions
Mutex Locks
 Simplest software based solution is mutex
lock
 Boolean variable indicating if lock is
available or not
 Protect a critical section by first
acquire() a lock then release() the lock
 Calls to acquire() and release() must
be atomic
 Usually implemented via hardware atomic
instructions
Mutex locks
do {
acquire lock
acquire lock
criticalsection
critical section
release lock
release lock
remainder section
remainder section
} while (true);
acquire() and release()
acquire()
acquire() {
while (!available)
while (!available)
; /*
; /*busy
busy
waitwait
*/ */
available = false;
available = false;
}
release()
release() {
available = true;
available = true;
}
Mutex Lock
available
available =
= True
False
True
Pi starts Pj starts
CPU switches
CPU switches to
to Pj
Pj
Pi
acquire( ) acquire()
CS Pi stops CS
release()
Pi stops
Semaphore
 Another synchronization tool that can be

used to solve several synchronization
problems
 Semaphore S – integer variable
 Can only be accessed via two indivisible
(atomic) operations
 wait() and signal()
Originally called P() and V()
 Binary vs. counting semaphore
Semaphore
wait(S) {
wait(S)
while (S <=
while (S 0)
<= 0)
; //
; // busy busy wait
wait
S--;
S--;
}
signal(S)
signal(S) {
S++;
S++;
}
Semaphore Usage
 Can solve various synchronization problems
 Critical Section Guard (initial value: 1)
 Precedence Enforcer (initial value: 0)
 Resource Counter (initial value: N)
Semaphore as Critical Section Guard
do {
Wait(S)
wait(s)
criticalsection
critical section
Signal(S)
signal(S)
remainder
remainder section
section
} while (true);
Semaphore as Critical Section Guard
SS =
= 01
0
Pi starts Pj starts
CPU switches
CPU switches to
to Pj
Pj
Pi
wait (S) wait (S)
CS Pi stops CS
signal(S)
Pi stops
Semaphore as Precedence Enforcer
 Consider P1 and P2 that require S1 to happen before S2
Create a semaphore “synch” initialized to 0

P1:
S1;
signal(synch); P1 stops Synch == 0
Synch 1
0
P2:
signal(synch)
wait(synch);
;
S2;
wait(synch) P2 stops
;
Semaphore Implementation with no Busy waiting
 With each semaphore there is an associated waiting queue

 Now a semaphore has two data items:
 value (of type integer)
 pointer to next record in the list
 Two operations:
 block – place the process invoking the operation on the appropriate
waiting queue
 wakeup – remove one of processes in the waiting queue and place it in
the ready queue
 typedef struct{
int value;
struct process *list;
} semaphore;
Implementation with no Busy waiting (Cont.)
wait(semaphore *S) {
S->value--;
S->value--;
if
if (S->value
(S->value << 0)
0) {{
add this process to S->list;
add this process to S->list;
block();
block();
} }
}
signal(semaphore *S) {
S->value++;
S->value++;
if
if (S->value
(S->value <=
<= 0)
0) {{
remove a process P from S->list;
remove a process P from S->list;
wakeup(P);
wakeup(P);
} }
}
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
S=0
1 Q=0
1
P0 P1
wait(S);
wait(S); wait(Q);
wait(Q);
wait(Q);
wait(Q); wait(S);
... ...
wait(S);
signal(S); signal(Q);
signal(Q); signal(S);
Deadlock and Starvation
 Starvation – indefinite blocking
 A process may never be removed from the
semaphore queue in which it is suspended
 Priority Inversion – Scheduling problem when
lower-priority process holds a lock needed by
higher-priority process
 Solved via priority-inheritance protocol
Classical Synchronization Problem
 Bounded Buffer Problem

 Readers-Writers Problem
 Dining Philosopher's Problem
Bounded Buffer Problem
 Producer/ consumer problem with bounded buffer
 Synchronization issues
 if the buffer is full then the producer should wait
 if the buffer is empty then the consumer should wait
 if producer is writing the produced data in the buffer than
the consumer should not access the buffer unless writing
process is completed
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
Bounded Buffer Problem (Cont.)
 The structure of the producer process
do {
...
...
/* produce an item
/* produce an in next_produced
item */
in next_produced */
...
...
wait(empty);
wait(empty);
wait(mutex);
wait(mutex);
...
...
/* add/*next
add produced to thetobuffer
next produced */
the buffer */
...
...
signal(mutex);
signal(mutex);
signal(full);
} while (true);
Bounded Buffer Problem (Cont.)
 The structure of the consumer process
Do {
wait(full);
wait(full);
wait(mutex);
wait(mutex);
......
/*
/* remove
remove an
an item
item from
from buffer
buffer to
to next_consumed
next_consumed */
*/
......
signal(mutex);
signal(mutex);
signal(empty);
signal(empty);
...
...
/*/*consume
consumethe
theitem
itemininnext
nextconsumed
consumed*/*/
...
...
} while (true);
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
Readers-Writers Problem
 Shared Data
 Data set
 Semaphore rw_mutex initialized to 1
 Integer read_count initialized to 0
 Semaphore mutex initialized to 1
Readers-Writers Problem (Cont.)
 The structure of a writer process
do {
wait(rw_mutex);
wait(rw_mutex);
......
/* /*
writing is is
writing performed */ */
performed
......
signal(rw_mutex);
} while (true);
Readers-Writers Problem (Cont.)
 The structure of a reader process
do {
wait(mutex);
wait(mutex);
read_count++;
if read_count++;
(read_count == 1)
if (read_count == 1)
wait(rw_mutex);
wait(rw_mutex);
signal(mutex);
signal(mutex);
...
/* reading is performed */
...
...
/* reading is performed */
wait(mutex);
...
read count--;
wait(mutex);
read_count--;
signal(rw_mutex);
signal(mutex);
signal(rw_mutex);
} while (true);
signal(mutex);
Dining-Philosophers Problem
5 1
2
4
 In the case of 5 philosophers

 Shared data
Bowl of rice (data set)
Semaphore chopstick [5] initialized to 1
Dining-Philosophers Problem Algorithm
 The structure of Philosopher i:
do {
wait
wait (chopstick[i]
(chopstick[i] ); );
wait wait
(chopStick[ (i + (i
(chopStick[ 1) +% 1)
5] %);5] );
//
// eat
eat
signal(chopstick[i]
signal (chopstick[i]););
signal
signal (chopstick[
(chopstick[ (i + (i
1) +% 1)
5] %);5] );
//// think
think
} while (TRUE);
 What is the problem with this algorithm?
5 1
2
4
Dining-Philosophers Problem Algorithm (Cont.)
 Deadlock handling
 Allow at most 4 philosophers to be sitting
simultaneously at the table.
 Allow a philosopher to pick up the
chopsticks only if both are available
(picking must be done in a critical section)
 Use an asymmetric solution -- an odd-
numbered philosopher picks up first the
left chopstick and then the right chopstick.
Even-numbered philosopher picks up
first the right chopstick and then the left
chopstick.
5 1
2
4
Topics discussed in this Chapter 5
 Why process synchronization is required?
 Race condition
 What is critical section problem?
 Conditions that must satisfied by a solution to CS problem
 Solutions to the CS problem
 Two-process solutions
 Hardware-based solutions
 Software-based solution
 Classical synchronization problem
End of Chapter 5

Chapter 5: Process Synchronization: Silberschatz, Galvin and Gagne ©2013 Operating System Concepts - 9 Edition

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Chapter 5: Process Synchronization: Silberschatz, Galvin and Gagne ©2013 Operating System Concepts - 9 Edition

Загружено:

Авторское право:

Доступные форматы

Chapter 5: Process

Store Reduced Data-

while (counter == BUFFER_SIZE) ;

 counter++ could be implemented as

 Consider the current value of “counter = 5”

 Consider this execution interleaving with “counter = 5”

 General structure of process Pi

CS1 CS1 is executed

CS1 is executed CS1

CS1 Pi stops CS1

 Summary of the previous lecture

 Software based solutions to the CS problem

 Some classical synchronization problems

 Concurrent access to shared data can result

Executes CLI command

boolean test_and_set (boolean *target )

 Hardware based solutions are hardware

 Another synchronization tool that can be

wait (S) wait (S)

Create a semaphore “synch” initialized to 0

 With each semaphore there is an associated waiting queue

 Bounded Buffer Problem

 n buffers, each can hold one item

 The structure of the producer process

 The structure of a writer process

 In the case of 5 philosophers

Вам также может понравиться