Movatterモバイル変換

Welcome toCS 345 Operating SystemsConcurrency, Chapter 6 (15)

Tip #15: “goes to” Operator -->■ Actually --> is not an operator!■ It’s a combination of two separate operators, i.e. -- and >.■ The conditional code decrements variable x, which returns x’s original (notdecremented) value, and then compares the original value with 0 usingthe > operator.int main(){int x = 10;while( x --> 0 ) // x goes to 0{printf("%d ", x);}printf("n");}9 8 7 6 5 4 3 2 1 0Concurrenty (15)22

Conditions of Deadlock■ Necessary (but not sufficient)■ Mutual exclusion – Everyone abides by the rules■ only one process may use a resource at a time.■ no process may access resource allocated to another.■ Hold-and-wait■ a process may hold allocated resources while awaiting assignment of otherresources.■ No preemption■ no resource can be forced to free a resource.■ Circular wait (sufficient)■ a closed chain of processes exists, such that each process holds at least oneresource needed by the next process in the chain (consequence of the firstthree conditions)■ Other conditions are necessary but not sufficient for deadlock - all fourconditions must hold for deadlock - Unresolvable circular wait is the definitionof deadlock!Concurrenty (15)3

Handling Deadlock■ Four general approaches exist for dealing with deadlock.1. Prevent deadlock■ by adopting a policy that eliminates one of the conditions.2. Avoid deadlock■ by making the appropriate dynamic choices based on the current state ofresource allocation.3. Detect Deadlock■ by checking whether conditions 1 through 4 hold and take action to recover.4. Ignore Deadlock■ System may hang, so??Concurrenty (15)4

1. Prevent Deadlock■ Eliminate Mutual Exclusion■ Use non-sharable resourcesConcurrenty (15)5■ Eliminate Hold and wait■ Guarantee that when a process requests a resource, it does not hold anyother resources■ System calls requesting resources precede all others■ A process can only request resources when it has none■ Usually results in low utilization of resources■ Allow Preemption■ If a process holds resources and requests more thatcannot be allocated, all its other resources are preempted■ If you can’t hold all, you can’t hold any■ Process is restarted only when it can have all■ Works for resources whose state can be easily saved andrestored later such as registers or memory.

1. Prevent Deadlock■ Eliminate Circular Wait■ Impose a total ordering of all resources (transitivity, antisymmetry)■ Require that all processes request resources in increasing order.■ Whenever a process requests a resource, it must release all resources that arelower■ With this rule, the resource allocation graph can never have a cycle.■ May be impossible to find an ordering that satisfies everyone■ Put resources in topological order.1 Card reader≡2 Printer≡3 Plotter≡4 Tape drive≡5 Card punch≡Processes request resources anytime butmust be made in numerical order.A process may request first printer andthen a tape drive (order: 2, 4), but not aplotter and then a printer (order: 3, 2).Concurrenty (15)6

2. Avoid Deadlock■ Allow general requests, but grant only when safe■ Assume we know the maximum requests (claims) for eachprocess■ Process must state it needs■ Ie. max of 5 A objects, 3 B objects, 2 C objects.■ Do not need to use its max claims■ Ie. Ok to set max=5 and only use 3■ Can make requests at any time and in any order■ Process Initiation Denial■ Track current allocations■ Assume all processes may make maximum requests at the same time■ Only start process if it can’t result in deadlock regardless of allocationsConcurrenty (15)17

Resource Allocation Denial■ Safe State – We can finish all processes by some schedulingsequence■ Example: Finish P1, P4, P2, P5, P3■ Banker’s Algorithm (Dijkstra)■ Reject a request if it exceeds theprocesses’ declared maximum claims■ Grant a request if the new state would be safe Determining if a state is safe Find any process Pi for which we can meet it’s maximum requestsDon't forget already allocated resources Mark Pi as “done”, add its resources to available resource pool State is safe if we can mark all processes as “done” Block a process if the resources are not currently available or thenew state is not safeConcurrenty (15)18

Banker’s Algorithm ExampleA B C9 3 6A B C1 1 2A B CP1 3 2 2P2 6 1 3P3 3 1 4P4 4 2 2Claim200P4112P3115P2P1 001CBAAllocationAvailableResource024P4301P3201P2P1 222CBAC - A200P4112P3115P2P1 001CBAAllocation Are we in a safe state? Yes!6 2 3Concurrenty (15)19

XYZ CarpentryCarpentry Company XYZ has 4 employees, 9clamps, 2 drills, and 2 bottles of glue.Chair 4 clamps, 1 drillDesk 6 clamps, 1 drill, 1 gluePicture Frame 4 clamps, 1 drill, 1 glueBook Case 6 clamps, 1 drill, 1 glueConcurrenty (15)20

XYZ CarpentryClamp Drill Glue9 2 2Clamp Drill Glue2 1 1Clamp Drill GlueP1 4 1 0P2 6 1 1P3 4 1 1P4 6 1 1ClaimAvailableResource114P4102P3014P2P1 013CBANeeded1. Are we in a safe state?2. P1 needs a drill. Is it OK to give it to him?3. Then, P4 needs a glue. Would you give it to him?Clamp Drill GlueP1 1 0 0P2 2 0 1P3 2 1 0P4 2 0 0Allotted4 2 1Yes!Concurrenty (15)21

XYZ CarpentryClamp Drill Glue9 2 2Clamp Drill Glue2 0 1Clamp Drill GlueP1 4 1 0P2 6 1 1P3 4 1 1P4 6 1 1ClaimAvailableResource114P4102P3014P2P1 003CBANeeded1. Are we in a safe state?2. P1 needs a drill. Is it OK to give it to him?3. Then, P4 needs a glue. Would you give it to him?Clamp Drill GlueP1 1 1 0P2 2 0 1P3 2 1 0P4 2 0 0Allotted4 2 1Yes!Yes!Concurrenty (15)22

1. Are we in a safe state? Yes2. P1 needs a drill. Is it OK to give it to him? Yes3. Then, P4 needs a glue. Would you give it to him?XYZ CarpentryClamp Drill Glue9 2 2Clamp Drill Glue2 0 1Clamp Drill GlueP1 4 1 0P2 6 1 1P3 4 1 1P4 6 1 1ClaimAvailableResource114P4102P3014P2P1 003CBANeededClamp Drill GlueP1 1 1 0P2 2 0 1P3 2 1 0P4 2 0 0AllottedNo!2 0 001Concurrenty (15)23

3. Detect Deadlock■ Avoidance methods tend to limit access to resources■ Instead, grant arbitrary requests and watch for deadlock■ Can vary how often we check■ Early detection vs. overhead of checks■ Algorithm (Stallings, Figure 6.9)■ Preparation:■ Create table of process requests, current allocations■ Note available resources■ Mark processes with no resources■ Mark any process whose requests can be met (requests £ available resources)■ Include resources from that process as ‘available’ (this process can finish)■ If multiple processes available, pick any■ If any processes cannot be marked, they are part of a deadlockConcurrenty (15)2424

1E0D000CBATemporary AvailableDetection Example■ Mark P4 (not holding anything someone else wants)A B C D E0 0 0 0 1Request AllocationAvailableResourceA B C D EP1 0 1 0 0 1P2 0 0 1 0 1P3 0 0 0 0 1P4 1 0 1 0 1A B C D EP1 1 0 1 1 0P2 1 1 0 0 0P3 0 0 0 1 0P4 0 0 0 0 0A B C D E2 1 1 2 111000 Mark P3, new available: 0 0 0 1 1 Cannot mark P1 or P2, so we are deadlockedConcurrenty (15)2525

000CBATemporary AvailableDeadlocked?Are we deadlocked? (Why or why not?)A B C0 0 0A B CP1 0 0 0P2 2 0 2P3 0 0 0P4 1 0 0P5 0 0 2RequestsAvailableA B CP1 0 1 0P2 2 0 0P3 3 0 3P4 2 1 1P5 0 0 2Allocation ResourceA B C7 2 6Concurrenty (15)2626

000CBATemporary AvailableDeadlocked?Are we deadlocked?A B C0 0 0A B CP1 0 0 0P2 2 0 2P3 0 0 0P4 1 0 0P5 0 0 2RequestsAvailableA B CP1 0 1 0P2 2 0 0P3 3 0 3P4 2 1 1P5 0 0 2Allocation ResourceA B C7 2 6010 313 315 427 627NoConcurrenty (15)2727

Deadlock Recovery■ Several possible approaches■ Abort all deadlocked processes■ Simple but common■ Back up processes to a previously saved checkpoint, then restart■ Assumes we have checkpoints and a rollback mechanism■ Runs risk of repeating deadlock■ Assumes that the deadlock has enough timing dependencies it won’t happen■ Selectively abort processes until deadlock broken■ Preempt resources until deadlock broken■ Must roll back process to checkpoint prior to acquiring key resourceConcurrenty (15)2828

Deadlock Recovery■ Process Termination■ Kill them all■ One at a time■ Consider priority■ Time computing■ Who has most resources■ Resource Preemption■ Who gets preempted■ Do you consider process rollback and starvationConcurrenty (15)2929

4. Ignore Deadlock■ Perhaps not as silly as it sounds - since handling deadlock has a veryhigh cost, it might be better to ignore it.■ Usually, the OS assumes that even if deadlock occurs, the loss of datawill be minimal and the probability of occurrence of such a situation isvery low.■ Use resource prioritization for heavily used resources, otherwise, don’tworry about deadlock.■ Handling deadlock requires an algorithm constantly running inbackground - is 20% of the CPU time worth trying to prevent an eventwith a probability of occurrence less than 0.01%?■ If the alternative is to have a forced reboot once a year, that might beacceptable.■ When is ignoring deadlock unacceptable?Concurrenty (15)3030

Handling Deadlock Strategies■ Questions:■ Does prevention/avoidance/detection really work?■ How often should you run a detection process?■ How often is deadlock likely to occur?■ How expensive is a detection process?■ May group resources into classes and have different deadlockstrategies for each class. Examples:■ Swap Space - Prevent deadlocks by requiring all space to be allocated at once.(Avoidance also possible.)■ Tapes/Files - Avoidance can be effective here, but prevention by orderingresources also possible.■ Main Memory - Preemption a good approach■ Internal Resources (channels, etc.) - Prevention by ordering resourcesConcurrenty (15)3131

Advantages/DisadvantagesApproach Allocation Policy Scheme Advantages DisadvantagesPreventionConservative; undercommits resourcesRequesting allresources at onceWorks well for process that performa single burst of activityNo preemption necessaryInefficientDelays process initiationFuture resource requirementsmust be known by processesPreemptionConvenient when applied toresources whose state can be savedand restored easilyPreempts more often thannecessaryResource orderingFeasible to enforce via compile-timechecksNeeds no run-time computationsince problem is solved in systemdesignDisallows incremental resourcerequestsAvoidanceBurden on systemanalysist; Midwaybetween detection andpreventionManipulate to findat least one safepathNo preemption necessaryFuture resource requirementsmust be known by OSProcesses can be blocked for longperiodsDetectionVery liberal; requestedresources are grantedwhere possibleInvoke periodicallyto test for deadlockNever delays process initiationFacilitates online handlingInherent preemption lossesIgnoranceExtremely liberal;requested resources arealways grantedInfrequent deadlockacceptableNo CPU overheadNot safety criticalInherent preemption lossesConcurrenty (15)3232

The Dining Philosophers Problem■ 5 philosophers who only eat and think.■ Each need to use 2 forks for eating.■ There are only 5 forks.1. When only two philosophers are eating, are we in a safe state?2. Is deadlock possible?3. How can deadlock be prevented?Concurrenty (15)3333

A B C D E1 1 1 1 1A B C D EP1 0 0 0 0 0P2 0 1 1 0 0P3 0 0 0 0 0P4 0 0 0 1 1P5 1 0 0 0 1A B C D EP1 1 1 0 0 0P2 0 0 0 0 0P3 0 0 1 1 0P4 0 0 0 0 0P5 0 0 0 0 0A B C D EP1 1 1 0 0 0P2 0 1 1 0 0P3 0 0 1 1 0P4 0 0 0 1 1P5 1 0 0 0 1Two Philosophers EatingA B C D E0 0 0 0 1Claim AllocatedAvailableResourcesTwo philosophers are eating. Are we in a safe state?C - A10011 11111YesConcurrenty (15)3434

0E0D000CBATemporary AvailableAre the Philosophers Starving?A B C D E0 0 0 0 0Request AllocationAvailableResourceA B C D EP1 0 1 0 0 0P2 0 0 1 0 0P3 0 0 0 1 0P4 0 0 0 0 1P5 1 0 0 0 0A B C D EP1 1 0 0 0 0P2 0 1 0 0 0P3 0 0 1 0 0P4 0 0 0 1 0P5 0 0 0 0 1A B C D E1 1 1 1 1No philosophers are eating. Are we deadlocked? YesConcurrenty (15)3535

Solution??■ Each philosopher is a process.■ One semaphore per fork:■ forks: array[0..4] of semaphores■ Initialization: forks[i].count:=1 for i:=0..4Process Pi:repeatthink;wait(forks[i]);wait(forks[(i+1)%5]);eat;signal(forks[(i+1)%5]);signal(forks[i]);forever• Deadlock if each philosopher starts by picking left fork!Concurrenty (15)3636

Another Solution■ A solution: admit only 4philosophers at a time thattries to eat■ Then 1 philosopher canalways eat when the other 3are holding 1 fork■ Introduce semaphore T thatlimits to 4 the number ofphilosophers “sitting at thetable”■ Initialize: T.count:=4Process Pi:repeatthink;wait(T);wait(forks[i]);wait(forks[(i+1)%5]);eat;signal(forks[(i+1)%5]);signal(forks[i]);signal(T);foreverConcurrenty (15)3737

Other Solutions…■ Buy more Forks■ Equivalent to increasing resources■ Put fork down if 2ndfork busy■ “livelock” if philosophers stay synchronized■ Room Attendant■ Only let 4 of the philosophers into the room at once■ May have 4 philosophers in room, but only 1 can eat■ Left-Handed Philosophers (asymmetric solution)■ Grab forks in the other order (right fork, then left fork)■ Any mix will avoid deadlock (linear ordering on forks)■ A philosopher may only pick up forks in pairs.■ must allocate all resources at onceConcurrenty (15)Concurrenty (15)3838

Movatterモバイル変換

Change Language

CSE34115 1115 - Ch-06 Concurrency 2.pptx

Embed presentation

Recommended

More Related Content

Similar to CSE34115 1115 - Ch-06 Concurrency 2.pptx

Recently uploaded

CSE34115 1115 - Ch-06 Concurrency 2.pptx

Editor's Notes