week 4 (2013-2014) operating systems

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



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



1. Inter-ProcessCommunication

3



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



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



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?



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



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



Local and Remote message

passing

9

Local Message Passing Remote Message Passing



2. ProcessSynchronization

10



Race Condition

11



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



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




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



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}


Group1

Race Condition

Critical Section



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



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



GMU – CS 571

Mutual Exclusion

Solution to Critical-Section Problem



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



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




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



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





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;



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);



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);

……





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;



DeadLock

27



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.



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



Resource allocation graphP1 P2

P3

r1 r2

Resource allocation graph

Without deadlock

P1 P2

P3

With deadlock



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.



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.




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




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



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.



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



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



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



P2 Runs to Completion




Thus, the state defined originally

is a safe state



Determination of an

Unsafe State



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.



ntroduction to Operating Systems

Lecture

week 4 (2013-2014) operating systems

Documents