teacher's notes - lec chapter 5 - process synchronization

7/25/2019 Teacher's Notes - Lec Chapter 5 - Process Synchronization

1/7


2/7

J.E.D.I.

In programming terms! we will define the counter as an array that would contain beers. -e

would need a variable to indicate the position in the array if where the bartender would placethe beers. The beerstac/ array and the top variable would have to be shared by thebartender and beerdriner processes! which would run concurrently.

These two processes would be running concurrently. $s the 'P0 can only process oneinstruction at a time! some conte)t switching would be occurring while each process runs.'onsider the scenario where this particular conte)t switch occurs

Beerdrinker: top = top 1

Bartender: beerstack[top] = new Beer // beer on top of an existing beer!

Bartender: top = top + 1

Beerdrinker: drink beerstack[top] // beerdrinker would drink an empt mug!

If the conte)t switch does not occur here! then! the two processes would run correctly.&owever! as the processes have no control of when or where the conte)t switch occurs! then

there is a chance that the system would end up in an inconsistent state.

-hat happens here is called a race condition! where the outcome of the modification of shared

variables is dependent on which process would modify the variables first.

1.3.2 Resource Competition

$nother problem that occurs in multiprocessor systems is resource competition. Since the

systems resources are limited! a process may need to wait for another process to finish beforeit can use system resources. 'onsider a printer being used by two applications. (oth can not

"perating Systems 1


3/7

J.E.D.I.

print at the same time.

1.3.3 Need for synchronization

Process synchronization addresses the race condition. Its purpose is to allow processes to

impose an order by which they are to run with respect to other processes. 2or e)ample! wecould impose that a conte)t switch not occur between the two lines of the bartender and thebeerdriner3s code. -e could also e)tend process synchronization so that a process wouldwait for another process before e)ecuting.

Synchronization also addresses resource competition. Synchronization primitives allows

processes to wait for resources and notify others when they are made available.

1.4 Other Synchronization ProblemsIn the previous section! we have discussed the producer*consumer problem. This sectiondiscusses other synchronization problems.

1.4.1 Critical Section Problem

$ critical section is a region of a process3 code where shared data between other cooperatingprocesses are manipulated. $s was discussed in the previous section! this modification shouldnot occur in parallel with the modification done by other processes.

Processes having a critical section would have its code divided into three parts

Entry section 4 code that implements the critical section problem solution

'ritical section 4 code that only one process can e)ecute

5emainder section 4 the rest of the code that has no effect on the critical section. The

remainder section can of course occur before the critical section.

$ny solution to the critical section problem should have the following characteristics6

7utual e)clusion 4 only a single process is allowed to run its critical section. $ll other

processes wishing to enter their critical section must wait as only one process is allowedto run its critical section.

Progress 4 If there is more than one process waiting to enter their critical section! thenthe selection of who ne)t to run their critical section must be done by the waiting

"perating Systems 8


4/7


5/7

J.E.D.I.

Each philosopher alternates between two states! either they are eating! or they are thining. $philosopher who wants to eat must have both chopstics left and right chopstics! if they arenot in use by that philosopher3s neighbor.

1. Synchronization SolutionsThis section discusses strategies that would allow process synchronization. -e will discuss

these algorithms as well as some of the solutions to our synchronization problems.

1.".1 #usy $ait

$ busy wait is a while*loop that does nothing! simply stopping program flow until the loop

conditional becomes false! set by another process.

To illustrate busy waits! we consider the following #incomplete% solution to a two processcritical section problem. -e consider two processes i and :. This is the code for process i.

do

w"ile #turn!=i$ % // loop w"ile it is not m turn et

criticalsection#$&

turn = '& // after i(m done) its '(s turn

remaindersection#$&

% w"ile #true$&

The code for process : is the reverse of this. 7utual e)clusion is established by this process asprocess i or : can only enter their critical section after they are allowed by the other process

e)iting theirs. &owever! this code fails the progress re;uirement! if process i loops very fastand waits at the busy loop! it would have to wait until : finishes its remainder section and

enters its own critical section again before it gets to have a turn.

1.".2 Wait and Notify

The problem with the busy wait is that the process wastes 'P0 cycles while waiting. $nalternatives are operating system primitives called wait#% and notify#%.

-hen a process invoes wait#% !it simply stops running! e)its the ready state and enters thewaiting state. It remains there until another process invoes a notify#i%! where i is the name ofthe process to be woen up.

-ith that! our partial solution to the critical section problem now becomes this6

do

if #turn != i$ wait#$& // stop running until i am notified b '

%

criticalsection#$&

turn = '& //after i is done done) its '(s turn

notif#'$& // wakeup ' if it is waiting*

remaindersection#$&

% w"ile #true$&

"perating Systems


6/7

J.E.D.I.

1.".3 Semaphores

"nce again! the problem with the two*process critical section solution is that a rapidlyprocessing process i would have to wait for : to finish its own critical section. $ semaphore isan ob:ect that modifies the wait#% and notify#% primitives to tae into account an integer value

and a lined list that will store the waiting processes.class emap"ore

int ctr = 1&

,rocess-ist -&

.oid wait#$

ctr = ctr 1&

if #ctr 0$

add t"is process to -&

block&

%

%

.oid notif#$

ctr = ctr + 1&if #ctr = 0$

get a process from - and resume its running

%

%

%

"ur two processes would now use the semaphore.

Semaphore s= >>shared by the two processes

do

s*wait#$&

criticalsection#$&s*notif#$&

remaindersection#$&

% w"ile #true$&

The initial value of ctr indicates how many processes are allowed to proceed. -hen a wait isinvoed on the semaphore! then the value is set to ?. $dditional processes wanting to enterthe critical section would find that invoing wait would halt the process! as the wait primitiveblocs all incoming processes.

@ow when a process invoes notify! the counter increments. If the counter is negative! then itmeans there are bloced processes and then proceeds to resume at least one of them in orderto enter the critical section.

The advantage of this is that if there are no processes waiting or running in the critical section!then the ctr has value , and wait#% will allow any process to pass through! without having to

wait for another process.

0sing semaphores! we now have a solution to the Dining Philosophers problem by having each

chopstic to be a semaphore.

emap"ore c"opstick[]&

do

c"opstick[i]*wait#$ //wait on t"e left c"opstick

c"opstick[#i+1$ 2 ]*wait#$ // wait on t"e rig"t c"opstick

eat&

c"opstick[#i+1$ 2 ]*notif#$ // release t"e rig"t c"opstick

c"opstick[i]*notif#$ // release t"e left c"opstick

"perating Systems A


7/7

J.E.D.I.

t"ink&

% until#true$

This solution is still not the best solution as it is prone to deadlocs #i.e. -hat if everyonegrabbed their left chopstic all at once%. Deadlocs are discussed in the succeeding chapter.

1.".4 %onitors

$ monitor is an ob:ect that only allows a single process to run any of its methods. It abstracts

process synchronization from the programmer! simply guaranteeing that if ever code is neededthat must be e)ecuted independently of other processes.

"perating Systems B

teacher's notes - lec chapter 5 - process synchronization

Documents