Date post: | 14-Jan-2016 |
Category: |
Documents |
Upload: | darcy-watkins |
View: | 221 times |
Download: | 0 times |
Process Synchonization
Chapter 6
Outline Process Synchronization The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores
Implementation Deadlocks and Starvation
Classic Problems of Synchronization The Bounded-Buffer Problem The Readers-Writers Problem The Dining-Philosophers problem
Process Synchronization Cooperating Processes
That can affect or be affected by other processes executing in the system.
Concurrent access to shared data may result in data inconsistency.
Maintaining data consistency requires mechanisms to ensure that cooperating processes access shared data sequentially.
Bounded-Buffer Problem
Shared data#define BUFFER_SIZE 10typedef struct {
. . .} item;
item buffer[BUFFER_SIZE];int in = 0, out = 0;int counter = 0;
Producer processitem nextProduced;…while (1) { while (counter == BUFFER_SIZE) ; buffer[in] = nextProduced; in = (in + 1) % BUFFER_SIZE; counter++;}
Bounded-Buffer Problem
item nextConsumed;while (1) { while (counter == 0) ; nextConsumed = buffer[out]; out = (out + 1) % BUFFER_SIZE; counter--;}
Bounded-Buffer ProblemConsumer process
“counter++” in assembly language
MOV R1, counter
INC R1 MOV counter, R1
“counter--” in assembly languageMOV R2, counter
DEC R2 MOV counter, R2
Bounded-Buffer Problem
If both the producer and consumer attempt to update the buffer concurrently, the machine language statements may get interleaved.
Interleaving depends upon how the producer and consumer processes are scheduled.
Bounded-Buffer Problem
Assume counter is initially 5. One interleaving of statements is:
producer: MOV R1, counter (R1 = 5) INC R1 (R1 = 6)consumer: MOV R2, counter (R2 = 5) DEC R2 (R2 = 4)producer: MOV counter, R1 (counter = 6)consumer: MOV counter, R2 (counter = 4)
The value of count may be either 4 or 6, where the correct result should be 5.
Bounded-Buffer Problem
Race Condition: The situation where several processes access and manipulate shared data concurrently, the final value of the data depends on which process finishes last.
Process Synchronization
Critical Section: A piece of code in a cooperating process in which the process may updates shared data (variable, file, database, etc.).
Critical Section Problem: Serialize executions of critical sections in cooperating processes
Process Synchronization
More Examples Bank transactionsAirline reservation
Process Synchronization
Bank Transactions
Balance
Deposit WithdrawalMOV A, Balance
ADD A, Deposited
MOV Balance, A
MOV B, Balance
SUB B, Withdrawn
MOV Balance, B
D W
Bank Transactions Current balance = Rs. 50,000Check deposited = Rs. 10,000ATM withdrawn = Rs. 5,000
Bank Transactions
Bank TransactionsCheck Deposit:
MOV A, Balance // A = 50,000ADD A, Deposit ed // A = 60,000
ATM Withdrawal:MOV B, Balance // B = 50,000
SUB B, Withdrawn // B = 45,000
Check Deposit:MOV Balance, A // Balance =
60,000
ATM Withdrawal:MOV Balance, B // Balance =
45,000
Assembly Language usage in C++ compiler
#include <iostream.h>main(){
int c = 5;__asm {
mov eax,cmov ebx,10add eax,ebxmov c,eax
}cout << c << endl;
}
#include <iostream.h>main(){
int c = 0;__asm {
mov eax,cadd eax,1mov c,eax
}cout << c << endl;
}
Software based solutions Hardware based solutions Operating system based
solution
Solution of the Critical Problem
do {
critical section
reminder section
} while (1);
entry section
exit section
Structure of Solution
Solution to Critical-Section Problem
2-Process Critical Section Problem N-Process Critical Section Problem Conditions for a good solution:
1. Mutual Exclusion: If a process is executing in its critical section, then no other processes can be executing in their critical sections.
Solution to Critical-Section Problem
2. Progress: If no process is executing in its critical section and some processes wish to enter their critical sections, then only those processes that are not executing in their remainder sections can decide which process will enter its critical section next, and this decision cannot be postponed indefinitely.
Solution to Critical-Section Problem
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.
Solution to Critical-Section Problem
AssumptionsAssume that each process executes at a nonzero speed
No assumption can be made regarding the relative speeds of the N processes.
Possible Solutions Only 2 processes, P0 and P1 Processes may share some common
variables to synchronize their actions. General structure of process Pi
do {
critical section
remainder section} while (1);
entry section
exit section
Algorithm 1
Shared variables: int turn;initially turn = 0
turn = i Pi can enter its critical section
Algorithm 1 Process Pi
do {
critical section
remainder section
} while (1); Does not satisfy the progress condition
while (turn != i) ;
turn = j;
Only two processes (P0 and P1) executing concurrently
P0 executes first, enters the critical region… and leaves it, leaving turn = 1.
Turn = 1 means P1 can enter the critical region, and finishes the critical section quickly, now turn = 0.
P0 enters the loop and finishes its critical region quickly. Giving turn to P1 (turn = 1)
At this point as we assumed that there is no process speed considerations say process P0 gets ready to run again while P1 (Turn=1) is still in its remainder section.
P0 cannot enters it critical region because Turn = 1. Violation of Condition (2. Progress)
Process P1Process P1do {
while (turn != 1) ;critical sectionturn = 0;reminder section
} while (1);
Process P0 Process P0 do {
while (turn != 0) ;critical sectionturn = 1;reminder section
} while (1);
Algorithm 2
Shared variablesboolean flag[2]; // Set to false flag [i] = true Pi ready to
enter its critical section
Algorithm 2 Process Pi
do {
critical section
remainder section
} while (1); Does not satisfy the progress condition
flag[i] = true;
while (flag[j]) ;
flag[i] = false;
Problem!!!!! Problem!!!!!
Tx: P0 sets flag[0] true to enter its regionTy: P1 sets its flag i.e. flag[1] to true to enter
its regionA Deadlock!!!!!Both will wait forever to enter their regions.
Process P0do {
flag[0] := true;while (flag[1]) ;critical sectionflag [0] = false;remainder section
} while (1);
Process P1do {
flag[1] := true;while (flag[0]) ;critical sectionflag [1] = false;remainder section
} while (1);
Algorithm 3
Combined shared variables of algorithms 1 and 2.
boolean flag[2]; // Set to false int turn=0;
Algorithm 3 Process Pi
do {
critical section
remainder section
} while (1);
flag[i] = true;turn = j;while (flag[j] && turn == j) ;
flag[i] = false;
Algorithm 3Meets all three requirements:
Mutual Exclusion: ‘turn’ can have one value at a given time (0 or 1)
Bounded-waiting: At most one entry by a process and then the second process enters into its CS
Algorithm 3
Progress: Exiting process sets its ‘flag’ to false … comes back quickly and set it to true again … but sets turn to the number of the other process
Meets all the requirementsSolves critical section problem of the two
processes
Process Pido {
flag [0]:= true;turn = 1;while (flag [1] and turn = 1) ;critical sectionflag [0] = false;remainder section
} while (1);
Process Pido {
flag [1]:= true;turn = 0;while (flag [0] and turn = 0) ;critical sectionflag [1] = false;remainder section
} while (1);
n-Process Critical Section Problem
Consider a system of n processes (P0, P1 ... Pn-1).
Each process has a segment of code called a critical section in which the process may change shared data.
n-Process Critical Section ProblemWhen one process is executing
its critical section, no other process is allowed to execute in its critical section.
The critical section problem is to design a protocol to serialize executions of critical sections.
Bakery Algorithm
By Leslie Lamport Before entering its critical section,
process receives a ticket number. Holder of the smallest ticket number enters the critical section.
If processes Pi and Pj receive the same number, if i < j, then Pi is served first; else Pj is served first.
Bakery Algorithm
The ticket numbering scheme always generates numbers in the increasing order of enumeration; i.e., 1, 2, 3, 4, 5 ...
Bakery Algorithm
Notations
(ticket #, process id #)
(a,b) < (c,d) if a < c or if a == c and b <
dmax (a0,…, an-1) is a number, k,
such that k ai for i = 0, …, n–1
Bakery Algorithm
Data Structuresboolean choosing[n]; int number[n];
These data structures are initialized to false and 0, respectively
Bakery Algorithm
Structure of Pi
do { choosing[i] = true;number[i] = max(number[0],
number[1], …, number [n – 1]) + 1;
choosing[i] = false;
Bakery Algorithm
Critical Section
for (j = 0; j < n; j++) { while (choosing[j]) ; while ( (number[j] != 0) &&
((number[j], j) < (number[i], i)) ) ;}
Bakery Algorithm
remainder section
} while (1);
number[i] = 0;
Bakery Algorithm do {
choosing[i] = true;number[i] = max(number[0], number[1], …, number [n – 1])+1;choosing[i] = false;for (j = 0; j < n; j++) {while (choosing[j]) ; while ((number[j] != 0) && (number[j,j] < number[i,i])) ;}critical sectionnumber[i] = 0;remainder section
} while (1);
Bakery Algorithm
Process NumberP0 3P1 0P2 7P3 4P4 8
Bakery Algorithm
P0 P2 P3 P4(3,0) < (3,0) (3,0) < (7,2) (3,0) < (4,3) (3,0) < (8,4)
Number[1] = 0 Number[1] = 0 Number[1] = 0 Number[1] = 0
(7,2) < (3,0) (7,2) < (7,2) (7,2) < (4,3) (7,2) < (8,4)
(4,3) < (3,0) (4,3) < (7,2) (4,3) < (4,3) (4,3) < (8,4)
(8,4) < (3,0) (8,4) < (7,2) (8,4) < (4,3) (8,4) < (8,4)
P1 not interested to get into its critical section number[1] is 0
P2, P3, and P4 wait for P0
P0 gets into its CS, get out, and sets its number to 0
P3 get into its CS and P2 and P4 wait for it to get out of its CS
Bakery Algorithm
P2 gets into its CS and P4 waits for it to get out
P4 gets into its CS
Sequence of execution of processes:
<P0, P3, P2, P4>
Bakery Algorithm
Meets all three requirements:Mutual Exclusion: (number[j], j) < (number[i], i) cannot be
true for both Pi and Pj
Bounded-waiting: At most one entry by each process (n-1 processes) and then a requesting process enters its critical section (First-Come-First-Serve)
Bakery Algorithm
Progress: Decision takes complete
execution of the ‘for loop’ by one process
No process in its ‘Remainder Section’ (with its number set to 0) participates in the decision making
Bakery Algorithm
Synchronization HardwareSynchronization Hardware
Bakery algorithm is very difficult to implement. Next attempt was to solve issues with a little help of Hardware
Two methodsDisable InterruptsSpecial Hardware Instructions
Normally, access to a memory location excludes other accesses to that same location.
Extension: designers have proposed machine instructions that perform two operations atomically (indivisibly) on the same memory location (e.g., reading and writing).
Synchronization Hardware
The execution of such an instruction is also mutually exclusive (even on Multiprocessors).
They can be used to provide mutual exclusion but other mechanisms are needed to satisfy the other two requirements of a good solution to the CS problem.
Synchronization Hardware
2023年4月21日 © Copyright Virtual University of Pakistan
Test and modify a word atomically.
boolean TestAndSet(boolean &target)
{
boolean rv = target;
target = true;
return rv;
}
Test-And-Set (TSL) Instruction
2023年4月21日 © Copyright Virtual University of Pakistan
Structure for Pi (‘lock’ is set to false)
while ( TestAndSet(lock) ) ;
lock = false;
do {
Critical Section
Remainder Section}
Solution with TSL
Is the TSL-based solution good?
No
Mutual Exclusion: SatisfiedProgress: SatisfiedBounded Waiting: Not satisfied
Solution with TSL
2023年4月21日 © Copyright Virtual University of Pakistan
Swaps two variables atomically
void swap (boolean &a, boolean &b)
{
boolean temp = a;
a = b;
b = temp;
}
Swap Instruction
2023年4月21日 © Copyright Virtual University of Pakistan
Structure for Pi ‘key’ is local and set to false
key = true;
while (key == true) swap(lock,key);
lock = false;
do {
Critical Section
Remainder Section}
Solution with Swap
Is the swap-based solution good?
No
Mutual Exclusion: SatisfiedProgress: SatisfiedBounded Waiting: Not satisfied
Solution with swap
2023年4月21日 © Copyright Virtual University of Pakistan
waiting[i] = true;key = true;while (waiting[i] && key) key = TestAndSet(lock);waiting[i] = false;
do {
Critical Section
A Good Solution ‘key’ local; ‘lock’ and ‘waiting’ global All variables set to false
2023年4月21日 © Copyright Virtual University of Pakistan
j = (i+1) % n;while ( (j != i) && !waiting[j] )
j = (j+1) % n;if (j == i)
lock = false;else
waiting[j] = false;
Remainder Section
A Good Solution
}
Is the given solution good?
Yes
Mutual Exclusion: SatisfiedProgress: SatisfiedBounded Waiting: Satisfied
Solution with Test-And-Set
Outline Process Synchronization The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores
Implementation Deadlocks and Starvation
Classic Problems of Synchronization The Bounded-Buffer Problem The Readers-Writers Problem The Dining-Philosophers problem
Semaphores
SemaphoresSynchronization tool
Available in operating systems
Semaphore S – integer variable that can only be accessed via two indivisible (atomic) operations, called wait and signal
Semaphores
Synchronization tool.Semaphore S – integer variableCan only be accessed via two indivisible (atomic) operations.
wait (S):
while S 0 do no-op;S--;
signal (S):
S++;Single CPU system disable all interrupts when executing Wait and
SignalMultiple CPU systems protect semaphore by TSL ..
Two Types of Semaphores
Counting semaphore – integer value (S) can range over an unrestricted domain.
Binary semaphore – integer value can range only between 0 and 1; can be simpler to implement.
Can implement a counting semaphore S as a binary semaphore.
Semaphoreswait(S){ while S 0
; //no-opS--;
}
signal(S){ S++;
}
n-Processes CS Problem Shared data:
semaphore mutex = 1;do { critical section
remainder section} while (1);
wait(mutex);
signal(mutex);
Remember wait and signal are atomic
P0
do { wait(mutex);
critical section signal(mutex);
remainder section
} while (1);
P1
do { wait(mutex);
critical section signal(mutex);
remainder section} while (1);
Wait executes as one indivisible operation that once executing cannot be preemptedSame holds for SignalIf both Processes execute Wait(mutex) at same time then only one would get access As Race condition would apply (wait and signal are atomic)
Is it a Good Solution?
Mutual Exclusion: YesProgress: YesBounded Waiting: No
SemaphoresMutexes
Mutex variable can have only two states.. Locked and Unlocked
Good when only mutual exclusion is requiredIf lock is 0 any process may set it to 1 using TSL
instruction and then READ or WRITE Shared dataIf lock is 1 then process may set it to 1 using TSL
(note no effect on lock state) and then Compare if it was 0 or not. It was non-zero (1) in this case hence process loops to check the state of the lock.
Mutex Code in Assembly
Enter_region:TSL Rx, Mutex //get lock value in Rx and Set lock to 1
CMP RX, 0 //Compare old value of Lock with 0
JZE ok //It was 0 hence enter critical region
CALL Thread_Yield //If already 1 then loop to enter_region
JMP enter_region
OKRET //If Lock was 0 then return and enter critical region
Leave_region:MOV MUTEX, 0 //Set lock to 0 so other waiting or looping process may enter
RET
Busy Waiting
Processes wait by executing CPU instructions
Problem? Wasted CPU cycles
Solution? Modify the definition of semaphore
Semaphore Implementation Define a semaphore as a record
typedef struct {
int value; struct process *L;} semaphore;
Semaphore ImplementationAssume two simple operations:
block() suspends the process that invokes it.
wakeup(P) resumes the execution of a blocked process P.
Semaphore ImplementationThe negative value of S.value
indicates the number of processes waiting for the semaphore
A pointer in the PCB needed to maintain a queue of processes waiting for a semaphore
Semaphore wait()Semaphore operations now
defined as void wait(semaphore S){
S.value--;if (S.value < 0) {
add this process to S.L;block();
}}
Semaphore signal()void signal(semaphore S){ S.value++; if (S.value <= 0) { remove process P from S.L; wakeup(P); }}
There are numerous Win32 API’s Block and Wakeup equivalent in win32 are ResumeThread(), SuspendThread,
WaitForSingleObject(), WaitForMultipleOjects() etc.. To create a semaphore variable
CSemaphore Object, CreateSemaphore() returns handle
Two Implementations
Busy-waiting version is better when critical sections are small and queue-waiting version is better for long critical sections (when waiting is for longer periods of time).
Process Synchronization
Use semaphore S initialized to 0 Pi Pj
A wait(S)signal(S) B
Execute statement B in Pj only after statement A has been executed in Pi
Process Synchronization Give a semaphore based solution
for the following problem:
Statement S1 in P1 executes only after statement S2 in P2 has executed, and statement S2 in P2 should execute only after statement S3 in P3 has executed.
Process Synchronization
P1 P2 P3 S1 S2 S3
Solution
Semaphore A=0, B=0;
P1 P2 P3 wait(A) wait(B) S3 S1 S2 signal(B)
signal(A)
Problems with Semaphores
Semaphores provide a powerful tool for enforcing mutual exclusion and coordinating processes.
But wait(S) and signal(S) are scattered among several processes. Hence, difficult to understand their effects.
Problems with Semaphores
Usage must be correct in all the processes.
One bad (or malicious) process can fail the entire collection of processes.
Deadlocks and Starvation A set of processes are said to be in
a deadlock state if every process is waiting for an event that can be caused only by another process in the set. Traffic deadlocks One-way bridge-crossing
Starvation (infinite blocking) due to unavailability of resources
Deadlock
P0 P1wait(S); wait(Q);wait(Q); wait(S);
signal(S); signal(Q);signal(Q); signal(S);
Deadlock
P0 P1
signal(S);
signal(Q);
Starvation (Infinite Blocking)
P0 P1wait(S); wait(S);
wait(S); signal(S);
Violation of Mutual Exclusion
P0 P1signal(S); wait(S);
wait(S); signal(S);
Main Cause of Problem and Solution
Cause: Programming errors due to the tandem use of wait() and signal() operations
Solution: Higher-level language constructs such as critical region (region statement) and monitor.
Producer consumer using Semaphores
#define N 100typedef int Semaphore;//Any critical instruction be executed by a semaphoreSemaphore mutex =1, empty = N, full = 0;void producer(void){
int item;while (TRUE){
item = produce_item();down(&empty);down(&mutex);insert_item(item);up(&mutex);up(&full);
}}
Producer consumer using Semaphores …
void customer(void){
int item;while(TRUE){
down(&full);down(&mutex);item = remove_item();up(&mutex);up(&empty);consume_item(item);
}}
Classical Problems of Synchronization
Bounded-Buffer Problem Do it yourself !
Readers and Writers ProblemDo it yourself
Dining-Philosophers ProblemSee Next Slides: But do it yourself
Readers-Writers Problem
Shared data
semaphore mutex, wrt;
Initially
mutex = 1, wrt = 1, readcount = 0
Readers-Writers Problem Writer Process
wait(wrt); …
writing is performed …
signal(wrt);
Readers-Writers Problem Reader Process
wait(mutex);readcount++;if (readcount == 1)
wait(wrt);signal(mutex);
…reading is performed
…wait(mutex);readcount--;if (readcount == 0)
signal(wrt);signal(mutex):
Dining-Philosophers Problem
Shared data
semaphore chopstick[5];
Initially all values are 1
Dining-Philosophers Problem Philosopher i:
do {wait(chopstick[i])wait(chopstick[(i+1) % 5])
…eat() …
signal(chopstick[i]);signal(chopstick[(i+1) % 5]);
…think …
} while (1);
Deadlock can occur if all the philosophers become hungry at the same time
Semaphores in Win32
CreateSemahore()WaitForSingleObject()ReleaseSemahore()
How to use SemaphoresHANDLE hs
hs= CreateSemaphore
( NULL, // no security attributes
InitialValue, // initial count .. For binary cMax =1
MaxValue, // maximum count .. For binary cMax =1
NULL); // pointer to semaphore-object name
WaitForSingleObject(hs,INFINITE);
count++; //simulation of critical region
ReleaseSemaphore(hs,1,NULL);
Monitors
Continuation of idea of ``object'' and object-oriented programming, abstract data types, data encapsulation, software engineering
Monitor contains programmer-defined operations that are provided mutual exclusion within the monitorOnly one process can be active inside a monitorProgrammer doesn’t need to code synchronization
explicitly
Integral part of the programming language so the compiler can generate the correct code to implement the monitor using the programming language run-time support
Monitors monitor monitor-name
{shared variable declarationsprocedure body P1 (…) {
. . .}procedure body P2 (…) {
. . .} procedure body Pn (…) {
. . .} {
initialization code}
}
Monitors… What if programmer wants explicit Synchronization
To allow a process to wait within the monitor, a condition variable must be declared, as
condition x, y;Condition variable can only be used with the operations wait
and signal. The operation
x.wait();means that the process invoking this operation is suspended until another process invokes
x.signal(); The x.signal operation resumes exactly one suspended process.
If no process is suspended, then the signal operation has no effect.
Normally x.signal resumes the process which first issued x.wait()
Dining Philosophers Example
monitor dp {
enum {thinking, hungry, eating} state[5];condition self[5];void pickup(int i) // following slidesvoid putdown(int i) // following slidesvoid test(int i) // following slidesvoid init()
{for (int i = 0; i < 5; i++)
state[i] = thinking;}
}
Dining Philosophers
void pickup(int i) {
state[i] = hungry;test[i];if (state[i] != eating)
self[i].wait();}
void putdown(int i) {
state[i] = thinking;// test left and right neighborstest((i+4) % 5);test((i+1) % 5);
}
Philosopher issues pickup() whenIt wants to eat. In this code it alsoChecks if chopsticks are available
Putdown is used after eating
Dining Philosophers
void test(int i) {
if ( (state[(i + 4) % 5] != eating) && (state[i] == hungry) && (state[(i + 1) % 5] != eating))
{state[i] = eating;self[i].signal();
}}
Check the states of neighboring philosophers. They must not be eatingi.e. must not be in critical region.
Dining Philosophers Example
Code is now simple. Dinning philospher picks up the chop sticks and if they are not available it waits
Dp.pickup(i)
Eat
Do.putdown(i)
Interesting Reading… Sec 2.3 Tanenbaum
Producer_Consumer Problem with monitors.
Base StructureMonitor ProducerConsumer
{Function Consumer
Function Producer
Function InsertItem
Function RemoveItem
}
Monitor With Condition Variables
Windows 2000 Synchronization
Uses interrupt masks to protect access to global resources on uniprocessor systems.
Uses spinlocks on multiprocessor systems.
Dispatcher objects may also provide events. An event acts much like a condition variable.
END OF CHAPTERNext: Memory Management