Upload
surumi-raf-sha
View
252
Download
0
Embed Size (px)
Citation preview
8/3/2019 Ch06 Synchronization
1/53
Synchronization
8/3/2019 Ch06 Synchronization
2/53
Synchronization
Background The Critical-Section Problem Petersons Solution Synchronization Hardware Semaphores Classic Problems of
Synchronization Monitors
8/3/2019 Ch06 Synchronization
3/53
Background
Concurrent access to shared data may result indata inconsistency.
Maintaining data consistency requiresmechanisms to ensure the orderly execution ofcooperating processes.
8/3/2019 Ch06 Synchronization
4/53
Producer-Consumer Problem Paradigm for cooperating processes, producer
process produces information that is consumedby a consumerprocess.
One solution to the producer-consumer problemuses shared memory.
To allow producer and consumer processes to runconcurrently, we must have available a buffer of
items that can be filled by the producer andemptied by the consumer.
The producer and consumer must besynchronized, so that the consumer does not try to
consume an item that has not yet been produced.
8/3/2019 Ch06 Synchronization
5/53
Bounded-Buffer Shared-Memory Solution
Shared data#define BUFFER_SIZE 10
Typedef struct {
. . .
} item;
item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;
Solution is correct, but can only useBUFFER_SIZE-1 elements
8/3/2019 Ch06 Synchronization
6/53
Bounded-Buffer Insert() Method
while (true) {
/* Produce an item */
while (((in + 1) % BUFFER_SIZE ) == out)
; /* do nothing -- no free buffers */
buffer[in] = item;
in = (in + 1) % BUFFER SIZE;
{
8/3/2019 Ch06 Synchronization
7/53
Bounded Buffer Remove() Method
while (true) {
while (in == out)
; // do nothing -- nothing toconsume
// remove an item from the buffer
item = buffer[out];
out = (out + 1) % BUFFER SIZE;return item;
{
8/3/2019 Ch06 Synchronization
8/53
Solution to Consumer-ProducerProblem
Suppose that we wanted to provide a solution tothe consumer-producer problem that fills all the
buffers. We can do so by having an integer countthat keeps track of the number of full buffers.Initially, count is set to 0. It is incremented by theproducer after it produces a new buffer and is
decremented by the consumer after it consumesa buffer.
8/3/2019 Ch06 Synchronization
9/53
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++;
}
8/3/2019 Ch06 Synchronization
10/53
Consumer
while (true) {
while (count == 0)
; // do nothing
nextConsumed = buffer[out];
out = (out + 1) % BUFFER_SIZE;
count--;
/* consume the item innextConsumed
}
8/3/2019 Ch06 Synchronization
11/53
Race Condition
count++ could be implemented as
register1 = countregister1 = register1 + 1count = register1
count-- could be implemented as
register2 = countregister2 = register2 - 1count = register2
Consider this execution interleaving with count = 5 initially:
S0: producer execute register1 = count {register1 =5}
S1: producer execute register1 = register1 + 1{register1 = 6}S2: consumer execute register2 = count {register2 =5}S3: consumer execute register2 = register2 - 1{register2 = 4}
8/3/2019 Ch06 Synchronization
12/53
Solution to Critical-Section
Problem
1.Mutual Exclusion - If process Pi is executing in itscritical section, then no other processes can beexecuting in their critical sections
2.Progress - If no process is executing in its criticalsection and there exist some processes that wishto enter their critical section, then the selection ofthe processes that will enter the critical sectionnext cannot be postponed indefinitely
3.Bounded Waiting - A bound must exist on thenumber of times that other processes are allowedto enter their critical sections after a process hasmade a request to enter its critical section and
before that request is granted
8/3/2019 Ch06 Synchronization
13/53
Mutexes : Mutual Exclusion
{parent process}
P1busy:=false;
P2busy:=false;initiate P1, P2;
end; {mutex}
var P1busy, P2busy : boolean;
8/3/2019 Ch06 Synchronization
14/53
Mutexes : Mutual Exclusion
process P1
beginwhile true do
begin
P1busy := true;
while P2busy do {keep testing};
critical-section;
P1busy:=false;other_P1busy_processing;
end{while}
End; {P1}
{parent process}
P1busy:=false;
P2busy:=false;initiate P1, P2;
end; {mutex}
var P1busy, P2busy : boolean;
8/3/2019 Ch06 Synchronization
15/53
Mutexes : Mutual Exclusion
process P1
beginwhile true do
begin
P1busy := true;
while P2busy do {keep testing};
critical-section;
P1busy:=false;other_P1busy_processing;
end{while}
End; {P1}
process P2
begin
while true do
begin
P2busy := true;
while P1busy do {keep testing};
critical-section;
P2busy:=false;
other_P2busy_processing;
end{while}
End; {P2}
{parent process}
P1busy:=false;
P2busy:=false;initiate P1, P2;
end; {mutex}
var P1busy, P2busy : boolean;
8/3/2019 Ch06 Synchronization
16/53
Petersons Solution
Two process solution Assume that the LOAD and STORE
instructions are atomic; that is, cannot beinterrupted.
The two processes share two variables: int turn;
Boolean flag[2]
The variable turn indicates whose turn itis to enter the critical section.
The flag array is used to indicate if aprocess is ready to enter the criticalsection. flag[i] = true implies that processPi is ready!
8/3/2019 Ch06 Synchronization
17/53
Algorithm for Process Piwhile (true) {
flag[i] = TRUE;
turn = j;
while ( flag[j] && turn == j);
CRITICAL SECTION
flag[i] = FALSE;
REMAINDER SECTION
}
8/3/2019 Ch06 Synchronization
18/53
Synchronization Hardware
The critical-section problem can be solved in auni-processor environment if we can forbid
interrupts to occur while a shared variable is
being modified. In this manner, we could besure that the current sequence of instructions
would be allowed to execute in order without
preemption. No other instructions would berun, so no unexpected modifications could be
made to the shared variable.
8/3/2019 Ch06 Synchronization
19/53
Synchronization Hardware
This solution is not feasible in a
multiprocessor environment. Disabling
interrupts on a multiprocessor can be
time-consuming, as the message is
passed to all the processors. This
message passing delays entry into each
critical section, and system efficiency
decreases.
8/3/2019 Ch06 Synchronization
20/53
Synchronization Hardware
Many machines provide special hardware
instructions that allow us either to test and
modify the content of a word or to swap
the contents of two words, atomically - as
one uninterruptible unit. These special
instructions can be used to solve the
critical-section problem.
8/3/2019 Ch06 Synchronization
21/53
TestAndndSet Instruction
Definition:
boolean TestAndSet (boolean
&target){
boolean rv = target;
target = TRUE;
return rv:}
8/3/2019 Ch06 Synchronization
22/53
Synchronization Hardware
The important characteristic is that this
instruction is executed atomically. Thus, if
two TestAndSet instructions are executed
simultaneously, each on a different CPU,
they will be executed sequentially in some
arbitrary order. If the machine supports
the TestAndSet instruction, then we can
implement mutual exclusion by declaring,
a Boolean variable lock, initialized to
8/3/2019 Ch06 Synchronization
23/53
Solution using TestAndSet Shared boolean variable lock., initialized to false. Solution:
while (true) {while ( TestAndSet (lock ))
; /* do nothing
// critical section
lock = FALSE;
// remainder section
}
8/3/2019 Ch06 Synchronization
24/53
Swap Instruction
Definition:
void Swap (boolean &a, boolean &b)
{boolean temp = a;
a = b;
b = temp:
}
8/3/2019 Ch06 Synchronization
25/53
Synchronization Hardware
It operates on the contents of two words
and it is executed atomically. If the
machine supports the Swap instruction,
then the mutual exclusion can be
provided by declaring a variable lock and
is initialized to false. In addition, each
process also has a local Boolean variable
key.
8/3/2019 Ch06 Synchronization
26/53
Solution using Swap Shared Boolean variable lock initialized to FALSE; Eachprocess has a local Boolean variable key.
Solution:while (true) {
key = TRUE;
while ( key == TRUE)Swap (lock, key );
// critical section
lock = FALSE;
// remainder section
}
8/3/2019 Ch06 Synchronization
27/53
Semaphore Synchronization tool that does not require busy waiting
Semaphore S integer variable
Two standard operations modify S: wait() and signal()
Originally called P() andV() Less complicated
Can only be accessed via two indivisible (atomic) operations
wait (S) {while S
8/3/2019 Ch06 Synchronization
28/53
Semaphore as General Synchronization Tool
Counting semaphore integer value can range overan unrestricted domain
Binary semaphore integer value can range onlybetween 0
and 1; can be simpler to implement Also known as mutex locks
Can implement a counting semaphore S as a binarysemaphore
Provides mutual exclusion Semaphore S; // initialized to 1
wait (S);
Critical Section
signal (S);
8/3/2019 Ch06 Synchronization
29/53
Semaphore Implementation Must guarantee that no two processes can
execute wait () and signal () on the samesemaphore at the same time
Thus, implementation becomes the criticalsection problem where the wait and signal code
are placed in the crtical 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 incritical sections and therefore this is not a goodsolution.
8/3/2019 Ch06 Synchronization
30/53
Semaphore Implementation with no Busy waiting
With each semaphore there is anassociated waiting queue. Each entry in awaiting queue 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 waitingqueue.
wakeup remove one of processes in thewaiting queue and place it in the readyqueue.
8/3/2019 Ch06 Synchronization
31/53
8/3/2019 Ch06 Synchronization
32/53
Deadlock and Starvation
Deadlock two or more processes are waitingindefinitely for an event that can be caused byonly one of the waiting processes
Let S and Q be two semaphores initialized to 1P
0
P1
wait (S); wait (Q);
wait (Q); wait (S);
. .
. .
. .
signal (S); signal (Q);signal (Q); signal (S);
Starvation indefinite blocking. A process maynever be removed from the semaphore queue inwhich it is suspended.
8/3/2019 Ch06 Synchronization
33/53
Classical Problems of Synchronization
Bounded-Buffer Problem Readers and Writers Problem
Dining-Philosophers Problem
8/3/2019 Ch06 Synchronization
34/53
Bounded-Buffer Problem
Nbuffers, each can hold one item Semaphore mutex initialized to the value
1
Semaphore full initialized to the value 0
Semaphore empty initialized to the valueN.
8/3/2019 Ch06 Synchronization
35/53
Bounded Buffer Problem (Cont.) The structure of the producer process
while (true) {
// produce an item
wait (empty);
wait (mutex);
// add the item to the buffer
signal (mutex);
signal (full);
}
8/3/2019 Ch06 Synchronization
36/53
Bounded Buffer Problem (Cont.) The structure of the consumer process
while (true) {
wait (full);
wait (mutex);
// remove an item from buffer
signal (mutex);
signal (empty);
// consume the removed item
}
8/3/2019 Ch06 Synchronization
37/53
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 thesame time. Only one single writer can accessthe shared data at the same time.
Shared Data Data set Semaphore mutex initialized to 1. Semaphore wrt initialized to 1. Integer readcount initialized to 0.
8/3/2019 Ch06 Synchronization
38/53
8/3/2019 Ch06 Synchronization
39/53
Readers-Writers Problem (Cont.) The structure of a reader process
while (true) {
wait (mutex) ;
readcount ++ ;
if (readercount == 1) wait (wrt) ;
signal (mutex)
// reading is performed
wait (mutex) ;
readcount - - ;
if (redacount == 0) signal (wrt) ;
signal (mutex) ;}
8/3/2019 Ch06 Synchronization
40/53
8/3/2019 Ch06 Synchronization
41/53
Dining-Philosophers Problem (Cont.) The structure of Philosopher i:
While (true) {
wait ( chopstick[i] );
wait ( chopStick[ (i + 1) % 5] );
// eat
signal ( chopstick[i] );
signal (chopstick[ (i + 1) % 5] );
// think
}
8/3/2019 Ch06 Synchronization
42/53
Problems with Semaphores
Correct use of semaphore operations:
signal (mutex) . wait (mutex)
wait (mutex) wait (mutex)
Omitting of wait (mutex) or signal (mutex) (orboth)
8/3/2019 Ch06 Synchronization
43/53
Monitors 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 ( .) { }
}
}
8/3/2019 Ch06 Synchronization
44/53
Schematic view of a Monitor
8/3/2019 Ch06 Synchronization
45/53
Condition Variables
condition x, y;
Two operations on a condition variable:
x.wait () a process that invokes the
operation is
suspended.
x.signal ()resumes one of processes(ifany)that
invoked x.wait ()
8/3/2019 Ch06 Synchronization
46/53
Monitor with Condition Variables
8/3/2019 Ch06 Synchronization
47/53
S l ti t Di i Phil h ( t)
8/3/2019 Ch06 Synchronization
48/53
Solution to Dining Philosophers (cont)
void test (int i) {if ( (state[(i + 4) % 5] != EATING) &&
(state[i] == HUNGRY) &&
(state[(i + 1) % 5] != EATING) ) {
state[i] = EATING ;
self[i].signal () ;
}}
initialization_code() {
for (int i = 0; i < 5; i++)
state[i] = THINKING;
}}
S l ti t Di i Phil h ( t)
8/3/2019 Ch06 Synchronization
49/53
Solution to Dining Philosophers (cont)
Each philosopher Iinvokes theoperationspickup()
and putdown() in the following sequence:
dp.pickup (i)
EAT
dp.putdown (i)
8/3/2019 Ch06 Synchronization
50/53
8/3/2019 Ch06 Synchronization
51/53
Monitor Implementation
For each condition variablex
, we have:
semaphore x-sem; // (initially = 0)
int x-count = 0;
The operation x.waitcan be implemented as:
x-count++;if (next-count > 0)
signal(next);
else
signal(mutex);
wait(x-sem);
x-count--;
8/3/2019 Ch06 Synchronization
52/53
Monitor Implementation
The operation x.signal can be implemented as:
if (x-count > 0) {
next-count++;
signal(x-sem);
wait(next);
next-count--;
}
8/3/2019 Ch06 Synchronization
53/53
Murugan R
Dept. of Computer ApplicationsMES College Marampally