OS Concurrency

7/18/2019 OS Concurrency

1/22

Copyright 2001 Stephen A. Edwards All rights reserved

Concurrency:Concurrency:

Mutual Exclusion &Mutual Exclusion &DeadlockDeadlock(In Some Selected(In Some Selected

OS)OS)byDeji Adebayo


2/22


What is concurrency

When something is happening at the same time (Webster's dictionary)

Computer science defines concurrency as a property of systems where several processesare executing at the same time, and may or may not interact with each other [1!

Can be regarded as the activation of several processes (that is, the execution of severalprograms) at the same time ["!

What is it#

$ Communication among processes$ %haring of and competing for resources

$ %ynchroni&ation of activities of multiple processes

$ llocation of processor time to processes

Concurrency arises in the same way at different levels of execution streams

$ ultiprogramming (ultiple applications)* interaction between multiple processes running onone C+ (pseudoparallelism)!

$ ultithreading interaction between multiple threads running in one process!

$ ultiprocessing (%tructured applications)* interaction between multiple C+s running multipleprocesses-threads (real parallelism)

$ .istributed +rocessing (/perating system structures)* management of multiple processes

executing on multiple distributed computer system!

1


3/22


Examples of Concurrency

Hardware examples:

processor can have multiple cores (multicore) computer can have multiple processors

networ0 can have multiple computers (rid

computing)

n internet has multiple networ0s

ll combinations of the above

Software examples:ultiprogramming, or running a lot of programs

concurrently (the /!%! has to multiplex their executionon available processors)! 2!g!

downloading a file listening to streaming audio having a cloc0 running chatting printing something

%imulation programs+ipes * for example

Difficulties with concurrency a can of wormsllocation of shared resources between processes of different priorities

3 C+, emory, 4nput-output devices5ace condition may result in unpredictable behavior!utual exclusion can prevent race conditions, but may in turn lead toDining Philosophers problem:

.eadloc0

* situation whereby two processes compete for two resources, and after each of them have

reserved one of the resources they discover that the other resource is ta0en6

%tarvation

* 7he processes execute without advancing, for instance by endless testing on a flag!

2


4/22


DINING PHILOSOPHERS PROLE!

The Problem

8ive philosophers live in a house!

7hin0ing and 2ating(+rocesses) is all

they do!

2ach philosopher re9uires two

for0s(5esources) to eat spaghetti!

+roblems of .eadloc0 and

%tarvation-:iveloc0

Prescribed Solutions

sing %emaphoressing a onitor


5/22


!hether Processes or Threads:Three "asic #nteractions

+rocesses unaware of each other$ they must use shared resources independently, without

interfering, and leave them intact for the others

+rocesses indirectly aware of each other$ they wor0 on common data and build some result together

via the data

+rocesses directly aware of each other$ they cooperate by communicating, e!g!, exchanging messages

$


6/22


Race Con"ition # Critical Re$ion

race condition occurs when

$ ultiple processes or threads read and write data items$ 7hey do so in a way where the final result depends on the order of execution of

the processes!

7he output depends on who finishes the race last!

How to a%oid race conditions&

8ind a way to 0eep the instructions together

$ this means actually! ! ! reverting from too much interleaving and going bac0 to;indivisible< bloc0s of execution66

$ 7he ;indivisible< execution bloc0s are critical regions$ a critical region (aka critical section) is a section of code that may be executed

by only one process or thread at a time!

7hus, the execution of critical sections must be mutually exclusive (e!g!, at most oneprocess can be in critical section at any time)!

'


7/22


!utual Exclusion %!&'E()

mutual exclusion (mutex) is a program ob=ect that prevents simultaneous access to a sharedresource!

/nly one thread owns the mutex at a time, thus a mutex with a uni9ue name is created when aprogram starts!

When a thread holds a resource, it has to loc0 the mutex from other threads to preventconcurrent access of the resource! pon releasing the resource, the thread unloc0s the mutex!

utual exclusion is one of the control problems faced in the case of competing processes! 7he

enforcement of mutex creates two additional control problems> deadloc0 and starvation(%tallings)!

(utual )xclusion *onditions

4f we could arrange matters such that no two processes were ever in their critical sectionssimultaneously, we could avoid race conditions!

We need four conditions to hold to have a good solution for the critical section problem (mutualexclusion)!

$ ?o two processes could be simultaneously inside their critical section!

$ ?o assumptions should be made about the speeds and the numbers of C+s!

$ ?o process running outside its critical section should bloc0 other processes!

$ ?o process would have to wait forever in order to enter its critical section!

+


8/22

Copyright 2001 Stephen A. Edwards All rights reserved ,


9/22


Proposals for *chie+in$ !utual Exclusion

7he mutex problem is to devise a protocol (pre or post) to 0eep two or more threads from being intheir critical sections at the same time!

7anenbaum examine proposals for critical*section problem or mutual exclusion problem!

Problem

When one process is updating shared modifiable data in its critical section, no other process shouldbe allowed entering its critical section!

Proposal 1- Disablin. #nterrupts /Hardware Solution0

2ach process disables all interrupts =ust after entering in its critical section and re*enables allinterrupts =ust before leaving critical section! With interrupts turned off the C+ could not beswitched to other process! @ence, no other process will enter its critical section and mutual exclusionachieved!

*onclusion4t is unwise to give user process the power to turn off interrupts!

Proposal , - Loc. /aria0le %Soft1are Solution)

4n this solution, we consider a single, shared, (loc0) variable, initially A! When a process wants toenter in its critical section, it first test the loc0! 4f loc0 is A, the process first sets it to 1 and then entersthe critical section! 4f the loc0 is already 1, the process =ust waits until (loc0) variable becomes A!7hus, a A means that no process in its critical section, and 1 means hold your horses * some process isin its critical section!


10/22


Dea"loc.

/perating %ystem Concepts 3 Bth2dition, 8eb 1, "AAD


11/22


Dea"loc. Cont2"3

set of process is in a deadlock state if each process in the set is waiting for an event that can becaused by only another process in the set!

4n other words, each member of the set of deadloc0 processes is waiting for a resource that can bereleased only by a deadloc0 process!

?one of the processes can run, none of them can release any resources, and none of them can beawa0ened!

4t is important to note that the number of processes and the number and 0ind of resources possessed

and re9uested are unimportant! 7he resources may be either physical or logical!

2xamples of physical resources are +rinters, 7ape .rivers, emory %pace, and CPUCycles!

2xamples of logical resources are 8iles, %emaphores, and onitors!

7he simplest example of deadloc0 is where process 1 has been allocated non*shareable resourcesA,

say, a tape drive, and process " has be allocated non*sharable resourceB, say, a printer! ?ow, if it turnsout that process 1 needs resourceB (printer) to proceed and process " needs resourceA(the tapedrive) to proceed and these are the only two processes in the system, each is bloc0ed the other and alluseful wor0 in the system stops! 7his situation is termed deadloc0!

7he system is in deadloc0 state because each process holds a resource being re9uested by the otherprocess neither process is willing to release the resource it holds!

13


12/22


Preempta0le an" Nonpreempta0le Resources

5esources come in two flavorspreemptableand nonpreemptable

preemptable resource is one that can be ta0en away from theprocess with no ill effects!

$ Memoryis an example of a preemptable resource!

/n the other hand, a nonpreemptable resource is one that cannotbe ta0en away from process (without causing ill effect)! 8orexample,

$ CDresources are not preemptable at an arbitrary moment!

5eallocating resources can resolve deadloc0s that involvepreemptable resources!

.eadloc0s that involve nonpreemptable resources are difficult todeal with!

11


13/22


Coffman (1EB1) identified four () conditions that must hold simultaneously for there to be adeadloc0!

10 (utual )xclusion *ondition

7he resources involved are non*shareable!

)xplanation:t least one resource (thread) must be held in a non*shareable mode, that is, only oneprocess at a time claims exclusive control of the resource! 4f another process re9uests that resource, there9uesting process must be delayed until the resource has been released!

20 Hold and !ait *ondition

5e9uesting process hold already, resources while waiting for re9uested resources!

)xplanation:7here must exist a process that is holding a resource already allocated to it while waiting foradditional resource that are currently being held by other processes!

0 4o-Preempti%e *ondition

5esources already allocated to a process cannot be preempted

)xplanation:5esources cannot be removed from the processes until it might have use to completion orreleased voluntarily by the process holding it!

$0 *ircular !ait *ondition --- 7he processes in the system form a circular list or chain where eachprocess in the list is waiting for a resource held by the next process in the list!

Necessary an" Sufficient Dea"loc. Con"itions

12


14/22


Dealin$ 1ith Dea"loc. Pro0lem 4n general, there are four strategies of dealing with deadloc0 problem

1) 7he /strich pproach

Fust ignore the deadloc0 problem altogether

") .eadloc0 .etection and 5ecovery

.etect deadloc0 and, when it occurs, ta0e steps to recover

G) .eadloc0 voidance

void deadloc0 by careful resource scheduling

) .eadloc0 +revention

+revent deadloc0 by resource scheduling so as to negate at least one of the four conditions!

Deadloc5 Pre%ention

@avender in his pioneering wor0 showed that since all four of the conditions are necessary for deadloc0 tooccur, it follows that deadloc0 might be prevented by denying any one of the conditions!

") 2limination of ;utual 2xclusion< Condition

G) 2limination of ;@old and Wait< Condition

) 2limination of ;?o*preemption< Condition

D) 2limination of ;Circular Wait< Condition

1


15/22


Dea"loc. *+oi"ance

7his approach to the deadloc0 problem anticipates deadloc0 before it actually occurs! 7his

approach employs an algorithm to access the possibility that deadloc0 could occur and acting

accordingly! 7his method differs from deadloc0 prevention, which guarantees that deadloc0cannot occur by denying one of the necessary conditions of deadloc0!

4f the necessary conditions for a deadloc0 are in place, it is still possible to avoid deadloc0 by

being careful when resources are allocated! +erhaps the most famous deadloc0 avoidance

algorithm, due to .i=0stra [1EHD, is the Bankers algorithm. %o named because the process is

analogous to that used by a ban0er in deciding if a loan can be safely made!

Dea"loc. Detection llow system to enter deadloc0 state

.etection algorithm

5ecovery scheme

t this point, however we note that a detection*and*recovery scheme re9uires overhead thatincludes

$ not only the run*time costs of maintaining the necessary information and executing thedetection algorithm

$ but also the potential losses inherent in recovering from a deadloc06

1$


16/22


&NI( CONC&RRENC4 !ECH*NIS!S

UNIX provides a variety o !e"hanis!s or interpro"essor

"o!!#ni"ation$I%C& and syn"hroni'ation.

(ere) we loo* at the !ost i!portant o these+

%ipes

,essages

Shared !e!ory

Se!aphores

Signals

1'


17/22


LIN&( 5ERNEL CONC&RRENC4 !ECH*NIS!S

-or in#/) we have the ollowing !e"hanis!or I%C and syn"hroni'ation. %ipes

,essages

Shared !e!ory

Se!aphores

Signals

Ato!i" perations Spinlo"*s

arriers

1+

SOL*RIS 'HRE*D S4NCHRONI6*'ION


18/22


SOL*RIS 'HRE*D S4NCHRONI6*'IONPRI!I'I/ES

In addition to the "on"#rren"y !e"hanis!s oUNIX S34) Solaris s#pports o#r threadsyn"hroni'ation pri!itives+ ,#t#al e/"l#sion $!#te/& lo"*s

Se!aphores ,#ltiple readers) single writer $readers5writer&

lo"*s

Condition varia6les

1,


19/22


WINDOWS CONC&RRENC4 !ECH*NIS!S

7hile window) espe"ially window 8 has theollowing !e"hanis! or I%C andsyn"hroni'ation. 7ait -#n"tions

9ispat"her 6:e"ts Criti"al Se"tions

Sli! 3ead;7riter o"*s and Condition aria6les

o"*;ree Syn"hroni'ation

1


20/22


References

[1 7!I! %0aali, .epartment of +hysics, niversity of /slo 8J%

""A 3 "A11 - K"

[" 8undamentals of /perating %ystems by :4%725, +g! 1D

[G +rinciples of /perating %ystems Iy %ri L! 5amesh,+g! H"

[ bramson, 7! ;.etecting +otential .eadloc0s!< .r! .obbMsFournal , Fanuary "AAH!

[D Coffman, 2!, 2lphic0, !, and %hoshani, ! ;%ystem.eadloc0s!< Computing %urveys , Fune 1EB1!

[H Corbett, F! ;2valuating .eadloc0 .etection ethods forConcurrent %oftware!< 4222 7ransactions on %oftware2ngineering , arch 1EEH!

1


21/22


References %Cont2")

[B .imitoglou, ! ;.eadloc0s and ethods for 7heir

.etection, +revention, and 5ecovery in odern /perating%ystems!< /perating %ystems 5eview , Fuly 1EEN!

[N ray, F! 4nterprocess Communications in ?4O 7he ?oo0sand Crannies! pper %addle 5iver, ?F +rentice @all, 1EEB!

[E @all, I! Iee=Ms uide to nix 4+C! "A1A! .ocumentavailable in premium content section for this boo0!

[1A @olt, 5! ;%ome .eadloc0 +roperties of Computer

%ystems!< Computing %urveys , %eptember 1EB"!

23


22/22


!ank"ou#or

$istenin%Attenti&ely'

21

Documents

OS Concurrency