Ionoregulatory and oxidative stress issues associated with ...
ISSUES ASSOCIATED WITH COORDINATING PROCESS
-
Upload
contactmahtab786 -
Category
Documents
-
view
220 -
download
0
Transcript of 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
-
8/7/2019 ISSUES ASSOCIATED WITH COORDINATING PROCESS
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.
-
8/7/2019 ISSUES ASSOCIATED WITH COORDINATING PROCESS
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
-
8/7/2019 ISSUES ASSOCIATED WITH COORDINATING PROCESS
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
-
8/7/2019 ISSUES ASSOCIATED WITH COORDINATING PROCESS
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();printf(``X = %d\n'', x);
}
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?
-
8/7/2019 ISSUES ASSOCIATED WITH COORDINATING PROCESS
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(){
IncrementX();printf(``X = %d\n'', x);
}
ProcessB(){
IncrementX();printf(``X = %d\n'', x);
}
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
-
8/7/2019 ISSUES ASSOCIATED WITH COORDINATING PROCESS
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/7/2019 ISSUES ASSOCIATED WITH COORDINATING PROCESS
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
-
8/7/2019 ISSUES ASSOCIATED WITH COORDINATING PROCESS
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
-
8/7/2019 ISSUES ASSOCIATED WITH COORDINATING PROCESS
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);
-
8/7/2019 ISSUES ASSOCIATED WITH COORDINATING PROCESS
11/12
/* wait until done */}produce(){
int i;for (i=0; i
-
8/7/2019 ISSUES ASSOCIATED WITH COORDINATING PROCESS
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