week 4 (2013-2014) operating systems
Post on 04-Jun-2018
215 Views
Preview:
TRANSCRIPT
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 1/44
ntroduction to Operating Systems
Lecture
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 2/44
Lecture 4 contents1. Inter-Process Communication
2. Process Synchronization
Race Condition and producer-consumer problem Solution
Peterson’s Solution
Semaphore Operations
Deadlock Problem Solution
Prevention
Avoidance
2
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 3/44
1. Inter-ProcessCommunication
3
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 4/44
Inter-process Communication Inter process Communication: The OS provides the means for cooperating
processes to communicate with each other via an inter process
communication (IPC) facility.
Processes within a system may be independent or cooperating:
Independent process cannot affect or be affected by the execution of
another process
Cooperating process can affect or be affected by other processes,
including sharing data. Cooperating processes need interprocess
communication (IPC).Two models of IPC (Message passing, Sharedmemory)
4
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 5/44
Direct Communication Direct Communication: each process that wants to communicate must
explicitly name the recipient or sender of the communication. In this scheme,
the send and receive primitives are defined as:
send(P, message)- Send a message to process P.
receive(Q, message)- Receive a message from process Q.
A communication link in this scheme has the following properties:
A link is established automatically between every pair of processes that
want to communicate. The processes need to know only each other’s
identity to communicate.
A link is associated with exactly two processes.
Exactly one link exists between each pair of processes.
Disadvantage : The names of processes must be known - they can't be easily
changed since they are explicitly named in the send and receive.
5
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 6/44
Indirect Communication Indirect communication: the messages are sent to and received from
mailboxes, or ports. Each mailbox has a unique identification. In this scheme,
a process can communicate with some other process via a number of
different mailboxes. Two processes can communicate only if they share a
mailbox. The send and receive primitives are defined as follows:
send (A, message)- Send a message to mailbox A
receive (A, message)- Receive a message from mailbox A.
In this scheme, a communication link has the following properties:
A link is established between a pair of processes only if both members of
the pair have a shared mailbox.
A link may be associated with more than two processes.
A number of different links may exist between each pair of
communicating processes, with each link corresponding to one mailbox.
Disadvantage : May cause confusion with multiple receivers - if several
processes have outstanding receives on a mailbox, which one gets amessage?
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 7/44
Blocking and Non-Blocking• Message passing may be either blocking or non-blocking
• Blocking is considered synchronous
•
Blocking send has the sender block until the message is received• Blocking receive has the receiver block until a message is available \
• Non-blocking is considered asynchronous
• Non-blocking send has the sender send the message and continue
• Non-blocking receive has the receiver receive a valid message or null
7
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 8/44
Local and Remote message
passing Local procedure call (LPC) Only works between processes on the same system.
Uses ports (like mailboxes) to establish and maintain communication channels
Communication works as follows:
The client opens a handle to the subsystem’s connection port object
The client sends a connection request
The server creates two private communication ports and returns the handle
to one of them to the client
The client and server use the corresponding port handle to send messages or
callbacks and to listen for replies
Remote procedure call (RPC) abstracts procedure calls between processes on
networked systems.
Uses Sockets in addition to ports.
A socket is defined as an endpoint for communication.
Concatenation of IP address and port.
The socket 161.25.19.8:1625 refers to port 1625 on host 161.25.19.8
Communication consists between a pair of sockets 8
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 9/44
Local and Remote message
passing
9
Local Message Passing Remote Message Passing
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 10/44
2. ProcessSynchronization
10
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 11/44
Race Condition
11
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 12/44
Race Condition Problem Fact of Life 1: Concurrent access to shared data may result in data
inconsistency
Fact of Life 2: Maintaining data consistency requires mechanisms to
ensure the orderly execution of cooperating processes.
Race Condition: The situation where several processes access and
manipulate the same data concurrently and the outcome of execution
depends on the particular order in which the access take place.
12
Critical section : Section (Segment) of the code werethe shared data is accessed n competing processes.
Entry Section : Code that requests permission to enter
its critical section.
Exit Section : Code that is run after exiting the critical
section
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 13/44
Producer- Consumer Problem
• Concurrent access to shared data may result in datainconsistency
• Maintaining data consistency requires mechanisms to ensurethe orderly execution of cooperating processes
• An example that shows this concurrency is the access of a
consumer and producer procedure for data in a buffer
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 14/44
Producer- Consumer Problem
14
• Suppose that we wanted to provide a solution to the consumer-producerproblem that fills all the buffers.• Have an integer count that tracks the number of full buffers.•
Initially, count is set to 0.• Producer increments count after producing a buffer• Consumer decrements after consuming a buffer
Producer Consumer
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 15/44
count++ could be implemented as
register1 = countregister1 = register1 + 1count = register1
count-- could be implemented as
register2 = countregister2 = register2 - 1count = register2
Possible execution (with “count = 5” initially): S0: producer executes register1 = count {register1 = 5}S2: consumer executes register2 = count {register2 = 5}S1: producer executes register1 = register1 + 1 {register1 = 6}S3: consumer executes register2 = register2 - 1 {register2 = 4}S4: producer executes count = register1 {count = 6 }S5: consumer executes count = register2 {count = 4}
Producer- Consumer Problem
Group1
Race Condition
Critical Section
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 16/44
Shared counters among threads Possible result: lost update!
One other possible result: everything works.
Difficult to debug
Called a “race condition”
hits = 0 + 1
read hits (0)
hits = 0 + 1read hits (0)
T1 T2
hits = 1
hits = 0
time
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 17/44
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 entry 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
17
Solution to Critical-Section Problem
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 18/44
GMU – CS 571
Mutual Exclusion
Solution to Critical-Section Problem
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 19/44
19
Solution to Critical-Section Problem To the Solve the Critical-Section Problem, we are going to show
two algorithms:
1. Peterson’s Solution : Serve two processes only
2. Semaphore : Suffers from deadlock
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 20/44
Peterson’s Solution Peterson’s solution is restricted to two processes that alternate
execution between their critical sections and remainder sections.
Assume two processes P0 and P1 share two data items:
int turn; boolean flag[2]
The variable turn indicates whose turn it is to enter its criticalsection.
If turn == i,
Then Pi is allowed to execute in its critical section. The flag array is used to indicate if a process is ready to enter its
critical section.
If flag[i] is true,
Then Pi is ready to enter its critical section.
20
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 21/44
Peterson’s Solution
21
Process Pi:
repeat
flag[i]:=true;
// I want inturn:=j;
// but you can go first!
while(flag[j]&& turn==j);
CS
flag[i]:=false;
// I’m done
RS
forever
Wait or Continue testing until
process P j change the turn to i
Change the turn to j
When the turn is changed to i, the process goes to the critical section.
Process flag his need to enter the critical section
Process flag the finalization of the critical section
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 22/44
22
Process P0:
repeat
flag[0]:=true;
// 0 wants in
turn:= 1;
// 0 gives a chance to 1
while
(flag[1]&turn=1);
CS
flag[0]:=false;// 0 is done
RS
forever
Process P1:
repeat
flag[1]:=true;
// 1 wants inturn:=0;
// 1 gives a chance to 0
while
(flag[0]&turn=0);
CS
flag[1]:=false;
// 1 is done
RS
forever
Peterson’s Solution
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 23/44
Peterson’s Solution
Mutual exclusion : The following two observations imply that P0 and P1
could not have successfully executed their while statement at thesame time:
Each Pi enters its critical section only if either flag[j]==false or turn == i.
If both processes are in the CS, then flag[j]=flag[i]=0.
Progress : The ready process Pi {of flag[i] is true} will enter the critical
section, When process P j is done with the critical section and sets theturn value .
Bounded Waiting : Pi enters the critical section only after at most
entry by P j .
23
Meets all three requirements for the solving the critical section problem;
This solution solves the critical-section problem for two processes only;
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 24/44
Semaphore is an integer variable S, of value 0 (in use) or 1 (free to access).
The value semaphore S is initialy free. The critical section has a semaphore
and the queue of waiting processes.
If a process P tries access the critical section, it checks S, if its values is 0,
it waits until its value is changed to a value greater than zero, one.
When S is 1, the lock is released, this indicates that the critical section is
free be accessed by the next waiting process. P access the critical section,
and set S to 0.
After P finishes working in the critical section it signals the release of the
lock by setting S to 1.
24
Semaphores’ Solution
Shared : semaphore S;Init: S = 1;
Wait(S) {while(S ≤ 0);
S--;}
Signal(S) {S++;
}
Process Pi from the queuedo {
wait(S);Critical Sectionsignal(S);
} while (1);
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 25/44
GMU – CS 571
Process A:
…….
wait (mutex);
Balance = Balance– 100;
signal (mutex);
……
Shared data:
int Balance;
semaphore mutex; // initially mutex = 1
Process B:
…….
wait (mutex);
Balance = Balance + 200;signal (mutex);
……
Semaphores’ Solution
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 26/44
Semaphores’ Solution
Mutual exclusion : If multiple processes are blocked on the same
semaphore s, only one of them will be awakened when anotherprocess performs signal(s) operation.
Progress : The highest priority queued waiting process Pi will enter the
critical section, When semaphore is released from the critical section.
Bounded Waiting : The implementation of the waiting queue may
result in a situation where two processes are waiting indefinitely for asignal() call from other waiting processes. This is named as a deadlock
status. Or a process may wait indefinitely for the critical section,
because its turn or priority for entry is not valid, this is named as
starvation.
26
Meets all three requirements for the solving the critical section problem;
This solution suffers from the possibility of deadlock;
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 27/44
DeadLock
27
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 28/44
In deadlock, processes halt because they cannot proceed and the resources are
never released. In starvation, the system overall makes progress using (and reusing)
the resources, but particular processes consistently miss out on being granted their
resource request.
28
Deadlock and starvation
Example of Deadlock
Processes P1 and P2, Resources S1 and S2
P1 is holding S2 P2 is holding S1
P1 is waiting S1 P2 is waiting S2
P1 will not release S2 until it has S1P2 will not release S1 until it has S2
Example of Starvation
Processes P1, P2, P3, and Resource R
• Each process requires periodic access
to R
• If P1 and P2 are repeatedly granted
access resource R, then P2 mayindefinitely be denied access to R.
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 29/44
29
• Wait-For-Graph (WFG)
Nodes – Processes in the system
Directed Edges – Wait-For blocking relation
• A Cycle represents a Deadlock
• Starvation - A process’ execution is permanently halted.
Process 1 Process 2
Resource 1
Resource 2Waits For
Waits For
Held By
Held By
Deadlock and starvation
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 30/44
Resource allocation graphP1 P2
P3
r1 r2
Resource allocation graph
Without deadlock
P1 P2
P3
With deadlock
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 31/44
31
Deadlock [Dining-Philosophers]
Shared data
semaphore chopstick[5];
Initially all semaphore values are 1
Five philosophers share a common
circular table. There are five chopsticks
and a bowl of rice (in the middle). When
a philosopher gets hungry, he tries to pick
up the closest chopsticks.
A philosopher may pick up only one
chopstick at a time, and cannot pick up a
chopstick already in use. When done, he
puts down both of his chopsticks, oneafter the other.
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 32/44
Let S and Q be two semaphores initialized to 1
P0 P1
wait(S); wait(Q);
wait(Q); wait(S);
M Msignal(S); signal(Q);
signal(Q) signal(S);
This attempt at a solution fails: It allows thesystem to reach a deadlock state in which eachphilosopher has picked up the chopstick to the
left, waiting for the chopstick to the right to beput down—which never happens
Deadlock – two or more processes are waitingindefinitely for an event that can be caused byonly one of the waiting processes.
Starvation – indefinite blocking. A process may
never be removed from the semaphore queue inwhich it is suspended.
Deadlock [Dining-Philosophers]
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 33/44
This attempt at a solution fails: It allows the system to reach a deadlock
state in which each philosopher has picked up the chopstick to the left,
waiting for the chopstick to the right to be put down—which never
happens, because
A. Each right fork is another philosopher's left chopstick , and no
philosopher will put down that fork until s/he eats, and
B. No philosopher can eat until s/he acquires the chopstick to his/her
own right, which has already been picked up by the philosopher to
his/her right as described above
33
Deadlock [Dining-Philosophers]
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 34/44
Mutual exclusion: The mutual exclusion condition must hold for non sharable
resources. For example, a printer cannot be simultaneously shared by several
processes. Shared resources on the other hand, do not require mutually exclusive
access, and thus cannot be involved in the deadlock. In general, however it is not
possible to prevent deadlocks by denying the mutual exclusion condition.
Hold and wait : To ensure that the hold and wait condition never occurs in the system,
we must guarantee that, whenever a process requests a resource, it does not hold any
other resources. A process may request some resources and use them before it can
request any other resources, however it must release all the resources that it is
currently allocated.
No preemption: The third necessary condition is that there be no preemption of
resources that have already been allocated. If a process that is holding some resourcesrequests another resource that it cannot be immediately allocated to it. Then all
resources currently being held are preempted.
Circular Wait : One way to ensure that the circular wait condition never holds is to
impose a total ordering of all resources types, and to ensure that each process
requests resources in an increasing order of enumeration.
34
Deadlock Conditions
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 35/44
Strategies for handling deadlocks
Deadlock prevention. Prevents deadlocks by restraining requests made toensure that at least one of the four deadlock conditions cannot occur.
Deadlock avoidance. Dynamically grants a resource to a process if theresulting state is safe. A state is safe if there is at least one executionsequence that allows all processes to run to completion.
Deadlock detection and recovery. Allows deadlocks to form; then finds
and breaks them.
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 36/44
1. A process acquires all the needed resources simultaneously before it begins its execution, therefore
breaking the hold and wait condition.
E.g. In the dining philosophers’ problem, each philosopher is required to pick up both forks at the
same time. If he fails, he has to release the fork(s) (if any) he has acquired.
Drawback: over-cautious.
2. All resources are assigned unique numbers. A process may request a resource with a unique number I
only if it is not holding a resource with a number less than or equal to I and therefore breaking the
circular wait condition.
E.g. In the dining philosophers problem, each philosopher is required to pick a fork that has a
larger id than the one he currently holds. That is, philosopher P5 needs to pick up fork F5 and then
F1; the other philosopher Pi should pick up fork Fi followed by Fi-1.
Drawback: over-cautions.
3. Each process is assigned a unique priority number. The priority numbers decide whether process Pishould wait for process Pj and therefore break the non-preemption condition.
E.g. Assume that the philosophers’ priorities are based on their ids, i.e., Pi has a higher prioritythan Pj if i <j. In this case Pi is allowed to wait for Pi+1 for I=1,2,3,4. P5 is not allowed to wait for P1.If this case happens, P5 has to abort by releasing its acquired fork(s) (if any).
Drawback: starvation. The lower priority one may always be rolled back. Solution is to raise thepriority every time it is victimized.
36
Deadlock Prevention
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 37/44
Resource Allocation Denial
do not grant an incremental resource request to a
process if this allocation might lead to deadlock.
State of the system reflects the current allocation of
resources to processes.
Safe state is one in which there is at least one sequence
of resource allocations to processes that does not result in
a deadlock.
Unsafe state is a state that is not safe.
37
Deadlock Avoidance
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 38/44
Determination of a Safe State
State of a system consisting of four processes and threeresources
Allocations have been made to the four processes
Amountof
existingresources
Resourcesavailable
afterallocation
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 39/44
P2 Runs to Completion
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 40/44
P1 Runs to Completion
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 41/44
P3 Runs to Completion
Thus, the state defined originally
is a safe state
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 42/44
Determination of an
Unsafe State
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 43/44
Deadlocks in Distributed Systems
43
• Resource Deadlock
Most Common.
Occurs due to lack of requested Resource.
• Communication Deadlock
A Process waits for certain messages before it
can proceed.
8/13/2019 Week 4 (2013-2014) Operating Systems
http://slidepdf.com/reader/full/week-4-2013-2014-operating-systems 44/44
ntroduction to Operating Systems
Lecture
top related