ISSUES ASSOCIATED WITH COORDINATING PROCESS

8/7/2019 ISSUES ASSOCIATED WITH COORDINATING PROCESS

1/12

TERM PAPER CSE 316

OPERATING SYSTEM

TOPIC-ISSUES ASSOCIATED WITH

COORDINATING PROCESS

SUBMITTED BY

RD1801B49

B.TECH (CSE)

SECTION- D181


2/12

ACKNOWLEDGEMENT

I RUCHI HEER of B-TECH (CSE) sectionD1801B49 has got the topic ISSUES ASSOCIATED

WITH COORDINATING PROCESS. This topic is

given to me by my respected SIR.

My friends helped in completion of this project. I have

worked hard on this project .

I am thankfull to my SIR for giving me such a topicin which I can show my skill. I hope this project will

be liked by everyone.


3/12

PROCESS

COORDINATI

ON

Process

coordination or concurrency

controldeals with mutual

exclusion andsynchronizatio

n.

Mutual exclusion--ensure that

two concurrent activities do

not access shared data

(resource) at the same time,critical region--set of

instructions that only oneprocess can execute.

Synchronization--using acondition to coordinate the

actions of concurrent activities.

A generalization of mutual

exclusion.

When considering process

coordination, we must keep inmind the following situations:

1.Deadlockoccurs when

two activities are

waiting each other and

neither can proceed. Forexample:

Suppose processes A

and B each need two

tape drives to continue,

but only one drive hasbeen assigned to each of

them. If the system has

only 2 drives, neither process can ever

proceed.

2.

Starvation occurs when

a blocked activity is

consistently passed over and

not allowed to run.

For example:

Consider two cpu bound jobs,

one running at a higher prioritythan the other. The lower

priority process will never be

allowed to execute. As we

shall see, somesynchronization primitives

lead to starvation.

MUTUAL

EXCLUSIONA way of making sure that if

one process is using a shared

modifiable data, the other

processes will be excluded

from doing the same thing.

Formally, while one processexecutes the shared variable,

all other processes desiring todo so at the same time moment

should be kept waiting; when

that process has finished

executing the shared variable,

one of the processes waiting;

while that process has finishedexecuting the shared variable,

one of the processes waiting to

do so should be allowed toproceed. In this fashion, each


4/12

process executing the shared

data (variables) excludes allothers from doing so

simultaneously. This is calledMutual Exclusion.

Note that mutual exclusion

needs to be enforced only

when processes access shared

modifiable data - when

processes are performingoperations that do not conflict

with one another they should be allowed to proceed

concurrently.

Mutual Exclusion

Conditions

If we could arrange matters

such that no two processeswere ever in their critical

sections simultaneously, wecould avoid race conditions.

We need four conditions to

hold to have a good solution

for the critical section problem(mutual exclusion).

No two processes mayat the same moment

inside their criticalsections.

No assumptions aremade about relative

speeds of processes or

number of CPUs.

No process shouldoutside its critical

section should blockother processes.

No process should wait

arbitrary long to enter

its critical section.

A solution to the mutual

exclusion problem shouldsatisfy the following

requirements:mutual exclusion

-- never allow more than

one process to execute

in a critical section

simultaneouslyenvironment independent

-- no assumptions on

relative process speedsor number of processors

resources shared only in

critical region-- no process stoppedoutside of the critical

region should blockother processes

bounded waiting

-- once a process has

made a request to enter

a critical region, there

must be a bound on thenumber of times that

other processes areallowed to enter the

critical sections before

the request is granted.

CRITICALSECTION


5/12

The key to preventing trouble

involving shared storage isfind some way to prohibit

more than one process from

reading and writing the shareddata simultaneously. That part

of the program where the

shared memory is accessed iscalled the Critical Section. To

avoid race conditions andflawed results, one must

identify codes in CriticalSections in each thread. The

characteristic properties of the

code that form a CriticalSection are

Codes that reference

one or more variables ina read-update-write

fashion while any ofthose variables is

possibly being altered

by another thread.

Codes that alter one ormore variables that are

possibly beingreferenced in read-

updata-write fashion

by another thread.

Codes use a data

structure while any part

of it is possibly being

altered by anotherthread.

Codes alter any part of a

data structure while it is possibly in use by

another thread.

Here, the important point is

that when one process is

executing shared modifiable

data in its critical section, no

other process is to be allowedto execute in its critical

section. Thus, the execution ofcritical sections by the

processes is mutuallyexclusive in time.

A critical section is a group of

instructions that must be

executed as a unit while otheractivity is excluded. Consider

two processes A and B:int x = 0; /* global sharedvariable (not Unix!) */ProcessA(){

IncrementX();printf(``X = %d\n'', x);

}

ProcessB(){


}

IncrementX(){

int Temp; /* localvariable */

Temp = x;Temp = Temp + 1;x = Temp;

}

Ifx starts with an initial value

of 0, what will its ending value

be?


6/12

2, (If we are lucky.)

1, otherwise

In our example, the three

statements inIncrementXare acritical section; once execution

in the critical section begins,

we must insure that it

completes before any other

activity executes that critical

section.

Because Temp is a variable

local toIncrementX, the

variable will be different forthe two processes.

How to ensure

thatIncrementXis executed as

a critical region? Need

primitives to enforce execution

as a critical

region:BeginRegion() andEn

dRegion. With mutual

exclusion the program is

int x = 0; /* global sharedvariable */ProcessA(){


}

ProcessB(){


}

IncrementX(){

int Temp; /* localvariable */

BeginRegion(); /* entercritical region */

Temp = x;Temp = Temp + 1;x = Temp;EndRegion(); /* exit

critical region */

}

Disabling Interrupts

(and Context

Switching)

One of the simplest ways toenforce mutual exclusion is to:

1.Disable interrupts at the

start of the critical

section.

2.

Ensure that the activity

doesn't give up the CPU before completing the

critical region (e.g.,don't context switch by

calling reschedor any

routine that does).

3.

Re-enable interrupts at

the end of the critical

section.BeginRegion(){

DisableInterrupts();}

EndRegion(){

EnableInterrupts();}

Disabling interrupts has the

following disadvantages:

1.

One must be careful notto disable interrupts for

too long; devices that

raise interrupts need to

be serviced!

2.

Disabling interrupts

prevents all otheractivities, even though


7/12

many may never

execute the same criticalregion. Disabling

interrupts is like using asledge hammer; a very

powerful tool, but

bigger than needed for

most jobs.

3.

Programmer mustremember to restore

interrupts when leavingthe critical section (may

not have user level

access)4.

The programmer must

be careful about nesting.Activities that disable

interrupts must restore

them to their previous

settings. In particular, if

interrupts are already

disabled before enteringa critical region, they

must remain disabledafter leaving the critical

region. Code in one

critical region may call

a routine that executes a

different critical region.

5.Technique is ineffective

on multiprocessorsystems, where multiple

processes may be

executing inparallel.

Parallel processing

execute multiple

processes in parallel.This differs from

multiprogrammingwhere only one process

can actually execute at

one time; the ``parallel''

execution is simulated.

Busy Waiting

Another approach is to define

a boolean variable that is set to` true'' if some activity is

currently executing the critical

region, ``false'' otherwise. One

(shortsighted!) solution might

be:

#define TRUE 1#define FALSE 0int mutex; /* alsocalled lock variable */

BeginRegion() /* Loopuntil safe to enter */{

while (mutex); /* do nothing

until FALSE */mutex = TRUE;

}

EndRegion() /* Exitcritical section */{

mutex = FALSE;}

BeginRegion();/* code for critical

section */EndRegion();

CodeforBeginRegion() compiles to

lw $14, mutex; load mutex into register14

beq $14, 0, $33; branch to $33 if mutex is0 (FALSE)$32:

lw $15, mutex; load mutex into register15

bne $15, 0, $32; branch to $32 if mutex is1 (TRUE)$33:


8/12

li $24, 1; load a 1 (TRUE) intoregister 24

sw $24, mutex; store value into mutex

Do our routines work correctly? No! A process that

finds mutex set to FALSE mayget past the bne statement but

be rescheduledbefore itactually changes the value

ofmutex. While it sits on the

ready list, another process that

test the value ofmutex will

find its value set to FALSE.

Solution: we need a

mechanism

foratomically fetching andsetting the value ofmutex.

That is, we want to fetch thevalue, and if it is FALSE, set it

to TRUE, all in one

instruction. If such a step takes

more than one instruction, aprocess could be interrupted or

rescheduled before it has achance to finish the job.

Test-and-Set Lock

Instruction

Most machine provides

provide an atomic ``test andset'' instruction for this

purpose. Most test-and-set

instructions have the followingsemantics:int test_and_set(int *pVar,int value){

int temp;

temp = *pVar;*pVar = value;

return(temp);}

BeginRegion andEndRegion c

an now be rewritten as:

BeginRegion() /* Loopuntil safe to enter */

{ while(test_and_set(&mutex, TRUE));

/* Loop until returnvalue is false */;}

EndRegion(){

mutex = FALSE;}

Advantages of aboveapproach:

1.

It works!

2.

It works for any numberof processors (used by

multiprocessor)

Disadvantage of aboveapproach: CPU busy-waits

until it can enter the critical

region, wasting resources.

Synchronization

int n = 0; /* shared by allprocesses */

main(){int produce(),

consume();CreateProcess(produce);CreateProcess(consume);/* wait until done */

}produce() /* ``produce''values of n */{

int i;for (i=0; i


9/12

consume() /* ``Consume'' andprint values of n */{

int i;for (i=0; i 0

THEN S := S - 1

ELSE (wait on S)

The V (or signal or wakeup or

up) operation on semaphore S,written as V(S) or signal (S),

operates as follows:

V(S): IF (one or more

process are waiting on S)

THEN (let one ofthese processes proceed)

ELSE S := S +1

Operations P and V are done

as single, indivisible, atomicaction. It is guaranteed that

once a semaphore operations

has stared, no other processcan access the semaphore until

operation has completed.

Mutual exclusion on the

semaphore, S, is enforced

within P(S) and V(S).

If several processes attempt a

P(S) simultaneously, only process will be allowed to

proceed. The other processes


10/12

will be kept waiting, but the

implementation of P and Vguarantees that processes will

not suffer indefinitepostponement.

Semaphores solve the lost-

wakeup problem.

Counting Semaphores are an

abstract entity provided by an

operating system (not the

hardware). Semaphores:

are named by a uniquesemaphore id

consist of a tuple (id,count, queue), where

count is an integer and

queue is a list of

processes.o a non-negative

count alwaysmeans that the

queue is emptyo a count of

negative n indicates that the queue

contains n waiting processes.

o a count of

positive n indicatesthat n resources

are available

and n requests

can be granted

without delay.

sem = semcreate(val) --creates a semaphore

with the given initial

value

semdelete(sem) -- delete

a semaphore wait(sem) -- decrement

the semaphore value. ifnegative, suspend the

process and place in

queue. (Also referred to

as P(), downin

literature.)

signal(sem) -- incrementthe semaphore value,

allow the first process inthe queue to continue.

(Also referred to as V(),

up in literature.)

First introduced by Dijkstra

(1965) as binary semaphores

and the operations were P(wait) and V (signal).

Can be used to implementmutual exclusion:

int sem;

sem = semcreate(1);

BeginRegion(){

wait(sem);}

EndRegion(){

signal(sem);}

Example with Fix

int produced, consumed; /*semaphores */int n = 0;main(){

int produce(),consume();

consumed = semcreate(0);produced = semcreate(1);

CreateProcess(produce);CreateProcess(consume);


11/12

/* wait until done */}produce(){

int i;for (i=0; i


12/12

http://web.cs.wpi.edu/~cs301

3/b00/week2-procco/week2-

procco.html
http://web.cs.wpi.edu/~cs3013/b00/week2-procco/week2-procco.htmlhttp://web.cs.wpi.edu/~cs3013/b00/week2-procco/week2-procco.htmlhttp://web.cs.wpi.edu/~cs3013/b00/week2-procco/week2-procco.htmlhttp://web.cs.wpi.edu/~cs3013/b00/week2-procco/week2-procco.htmlhttp://web.cs.wpi.edu/~cs3013/b00/week2-procco/week2-procco.htmlhttp://web.cs.wpi.edu/~cs3013/b00/week2-procco/week2-procco.html

ISSUES ASSOCIATED WITH COORDINATING PROCESS

Documents