Top Banner

of 320

10.1.1.72.4304_DeadLock

Apr 06, 2018

Download

Documents

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
  • 8/2/2019 10.1.1.72.4304_DeadLock

    1/320

    Deadlockisaconstantthreatinterminal-orientedsystems.Thiscomprehensivestudyofdeadlock-handlingtechniquesintroducesamethodforon-linedetectionindistributeddatabases.

    TheDeadlockProblem:AnOverview

    SreekaanthS.Isloor.

    T.AnthonyMarslandUniversityofAlberta

    Modernmultiprogrammingsystemsaredesigned

    tosupportahighdegreeofparallelismbyensuringthat

  • 8/2/2019 10.1.1.72.4304_DeadLock

    2/320

    asmanysystemcomponentsaspossibleareoperatingconcurrently.Theincreasingtrendamongcommercial

  • 8/2/2019 10.1.1.72.4304_DeadLock

    3/320

    rmsforon-lineoperations,especiallythoseinvolvingintegrateddatabases,andtheconsequentneedbyactiveusersforresponsivesystemshaveplacedheavydemandson

    operatingsystems.Compoundingthesedi culties,distributedprocessinghasarrivedasthesolution

    toincrementalsystemgrowth.Suchcontemporarysystemsexhibitahighdegreeofresource

    anddatasharing,asituationinwhichdeadlockisa

  • 8/2/2019 10.1.1.72.4304_DeadLock

    4/320

    constantthreat.Deadlocksarisewhenmembersofagroupofprocesseswhichholdresourcesareblockedinde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    5/320

    nitelyfromaccesstoresourcesheldbyotherprocesseswithinthegroup.Whennomemberofthegroupwillrelinquishcontroloveritsresources

    untilafterithascompleteditscurrentresourceacquisition,deadlockisinevitableand

    canbebrokenonlybytheinvolvementofsomeexternalagency.

    .NowatBellNorthernResearch,Ottawa.1

  • 8/2/2019 10.1.1.72.4304_DeadLock

    6/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    7/320

    Asetofprocessesbecomesdeadlockedasaconsequenceofexclusiveaccessandcircularwait.Thesimplestillustrationoftheseconditionsinvolvesonly

    twoprocesses,eachholding,forexclusiveaccess,adi erentresourceandeachrequesting

    accesstotheresourceheldbytheother.Theresultisacircular

    waitwhichcannotbebrokenuntiloneoftheprocesses

  • 8/2/2019 10.1.1.72.4304_DeadLock

    8/320

    releasesitsresourceorcancelsitsrequest.

    Inthisarticle,wesurveytheresourcemanagementproblemincomputersystemsbyreviewingthe

    principles,techniques,andtoolsinvolvedinhandlingandavoidingdeadlocks;wealsopropose

    anewmethodforhandlingdeadlockindistributeddatabases,closingwithsomecase

    studiesontheresourcemanagementprobleminlargecomputersystems.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    9/320

    Annotatedreferencestoworkscitedandacomprehensivebibliographyofsupplementarymaterialsareprovided.

    Examplesofdeadlock

    Thedeadlockproblem

    occursinmanydi erentcontexts,andanalogiescanbemadetoreal-lifesituations,

    providedoneinterpretstheprocessesandresourcesinvolvedappropriately.Forinstance,oneoften

    hearsabout\deadlockedpeacetalksbetweentwowarringnations.In

  • 8/2/2019 10.1.1.72.4304_DeadLock

    10/320

    thatcontext,thepeace-negotiatingpartiesofthetwocountriesaretheprocesses,andtheoccupiedterritoriescouldrepresenttheresourcesoverwhichexclusivecontrol

    issought.Thepeacetalkscouldbeblockedinde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    11/320

    nitelyifbothpartiesrefusetogiveupanyoccupiedlandwhiledemandingthereturnofsomelandheldbytheiradversary.

    Anothercommonexampleisthetra cdeadlock.Considerthesituation(Figure1)where

    fourcars,A,B,C,andD,arriveatanintersectionatapproximately

    thesametime.Topreventaccidentsatfour-waystopintersections,

  • 8/2/2019 10.1.1.72.4304_DeadLock

    12/320

    right-of-wayregulationsrequirethatAyieldtoB,BtoC,andsoon.AsfarasAisconcerned,partoftheintersection

    belongstoBforexclusiveuse,soAmustwaituntilBpasses.

    Acircularwaitisanessentialcomponentofthistra cdeadlock;ifall

    fourvehiclesmoveforward,occupyingasmuchoftheintersection

  • 8/2/2019 10.1.1.72.4304_DeadLock

    13/320

    aspossible,alltra ccomestoastandstill.Inthisillustration,thecarsaretheprocesses,whilethefourquartersoftheintersectionare

    theresourcesoverwhichexclusivecontrolisneeded.

    Thedeadlocksituation

    isdi erentdependingonwhetherthecarswanttoturnright,turnleft,

    orgostraight.Assumingtheexitrouteforeachcar

  • 8/2/2019 10.1.1.72.4304_DeadLock

    14/320

    isclear,theapparentdeadlockdoesnotmaterializewhenallthecarswishtomakearightturn,sincethecarsrequireaccessto

    onequarteroftheintersectionwhichnoothersdemand.Thingsaremoredi cult

    whenthecarswanttoproceedaheadorturnleft.Togostraight,

    carArequiresquarters1and2oftheintersection.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    15/320

    Inthesecircumstances,adeadlockarisessinceeachcarneedsexclusiveaccesstoaquarteroftheintersectiontowhichthecaronits

    rightsideholdsalegalright(controls).

    Thetra cproblemcan

    behandledthroughtheinterferenceofanexternalagency(e.g.,apoliceman)allocating

    spacetooneofthevehicles.Alternatively,somebusycities

  • 8/2/2019 10.1.1.72.4304_DeadLock

    16/320

    \cross-hatchimportantintersections,andrequirethatnovehicleenterthatareaunlessitsexitrouteisclear.Thecross-hatchingtechniqueensuresthatnoprocess

    willacquirearesource(occupytheintersection)whichitcannotsubsequentlyrelinquish(leave

    byaclearexit).Asapracticalmatter,tra cdeadlockisusuallyresolved

    byonedriveraggressivelyenteringtheintersection,preemptingitfrom

  • 8/2/2019 10.1.1.72.4304_DeadLock

    17/320

    theothers.Asanalternative,onemightforcevehiclestorollbackarandomdistanceandapproachthecrossroadsagain.Sinceeachdriverthus

    delayshisentrybyadi erentamount,theproblemcausedbytheirsimultaneous

    arrivaliseliminated.AsimilartechniqueisusedinEthernet1toresolveaccess

    conictsonitscommunicationmediumandisalsousualon

  • 8/2/2019 10.1.1.72.4304_DeadLock

    18/320

    contention-modetelecommunicationcircuits.

    Fordeadlocksthatmayoccurincomputeroperatinganddatabasesystems,wewillusetheterm\systemresourcequite

    broadlytorefertostoragemedia(e.g.,primarymemory,tapes,disks,anddrums),

    systemcomponents(e.g.,tapedrives,diskdrives,I/Ochannels,CPUs,readers,andprinters),

    andinformation

    2

  • 8/2/2019 10.1.1.72.4304_DeadLock

    19/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    20/320

    les,directories,programs,andsystemroutines).Considerasmallmultiprogrammingsystemwithasinglecardreaderandaprinter,inwhichtwouserjobs

    shareuseoftheprinterandthecardreaderbymeansofrequest

    andreleaseoperations,asgiveninstandardoperatingsystemstexts.2Dueto

    independentschedulingofthejobs,requestandreleaseoperationscan

  • 8/2/2019 10.1.1.72.4304_DeadLock

    21/320

    beinterspersedinseveraldi erentorders.Someofthesesequencesleadtoa\deadlyembrace,adeadlockwheretwojobs,forexample,holdthe

    printerandthecardreader,respectively,and|atthesametime|requesttheunitheld

    bytheother.

    Moregenerally,asetofwaitingprocessesforms

    acircularchainwhereeachprocessholdsatleastone

  • 8/2/2019 10.1.1.72.4304_DeadLock

    22/320

    resourceandmakesaconictingaccessrequestforsomeresourceheldbythenextprocessinthechain.Suchacircularwaitconditioncan

    arisewhenthefollowingnecessaryconditionshold:

    processesrequestexclusive

    controlofresources,

    processesholdresourcesallocatedtothemwhilewaitingfor

    additionalones,and

    nopreemptionofaresourcefrom

  • 8/2/2019 10.1.1.72.4304_DeadLock

    23/320

    aprocesscanbedonewithoutabortingtheprocess.Inmanywaystheseconditionsarequitedesirable.Forconsistency,datarecordsshouldbeheld

    untilupdateiscomplete.Similarly,preemption(thereclaimingofaresourcebythe

    system)cannotbedonearbitrarilyand,especiallywhendataresourcesareinvolved,must

    besupportedbyarollbackrecoverymechanism.Rollbackrestoresa

  • 8/2/2019 10.1.1.72.4304_DeadLock

    24/320

    processanditsresourcestoasuitablepreviousstatefromwhichtheprocesscaneventuallyrepeatitstransactions.

    Forthedatabasecase

    (Figure2),considertwoconcurrentlyexecutingprocessesPandQ,whichmodifyentities

    MandN.Letusassumethatthedatabasecorrectness(consistency)assertionon

    theentitiesisM=Nandthattheinitialvalues

  • 8/2/2019 10.1.1.72.4304_DeadLock

    25/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    26/320

    PP1:M=M+100P2:N=N+100QQ1:N=2*NQ2:M=2

    *MPROCESSPPROCESSQSTEPACTIONSTEPACTIONP0REQUESTENTITY

    MP1LOCKENTITYMP2READENTITYMP3WRITEENTITYM

    P4REQUESTENTITYNP5LOCKENTITYNP6READ

  • 8/2/2019 10.1.1.72.4304_DeadLock

    27/320

    ENTITYNP7WRITEENTITYNP8UNLOCKENTITYMP9UNLOCKENTITYNQ0REQUESTENTITYNQ1LOCKENTITYNQ2READ

    ENTITYNQ3WRITEENTITYNQ4REQUESTENTITYMQ5LOCKENTITY

    MQ6READENTITYMQ7WRITEENTITYMQ8UNLOCKENTITYN

    Q9UNLOCKENTITYM

    Figure2.Consistentdatabase

  • 8/2/2019 10.1.1.72.4304_DeadLock

    28/320

    deadlock.Thesequenceofstepsleadingtodeadlockisp0q0p1q1p2p3q2q3p4q4.

    sothatdatabasecorrectnessismaintained,concurrentoperationcanstillleadto

    deadlock.Thereforeaconsistencyresulthasbeendevelopedwhichrequiresthattheprocesses

    be\well-formedand\two-phase:"3

    Awell-formedprocessisonewhichlocks

    anentitybeforeactingonitfurtherandsubsequentlyunlocks

  • 8/2/2019 10.1.1.72.4304_DeadLock

    29/320

    it.Aprocessisthusrequiredtobedividedintogrowing(locking)andshrinking(unlocking)phases.The

  • 8/2/2019 10.1.1.72.4304_DeadLock

    30/320

    rstunlockactionsignalsthebeginningoftheshrinkingphase,afterwhichaprocesscannotissuealockrequestonanyentityinthe

    databaseuntilallotherentitiesheldhavebeenreleased.Inthecontextof

    Figure2,itisessentialtonotethattheprocessP(orQ)

    cannotunlockentityM(orN)beforelockingentityN

  • 8/2/2019 10.1.1.72.4304_DeadLock

    31/320

    (orM),ifitistomaintaindatabasecorrectness.Notealsothatunderconcurrentoperationtheinterleavedsequenceofactionsp0q0p1q1

    p2p3q2q3p4q4endsindeadlock.Severalotheraspectsof

    concurrentoperationsuchastransaction-,lock-,log-,andrecovery-managementneednotconcernus

    andhavebeendealtwiththoroughlyelsewhere.4

  • 8/2/2019 10.1.1.72.4304_DeadLock

    32/320

    Basicapproachestodeadlockhandling

    One-basicstrategyforhandlingdeadlocksistoensureviolationofatleastoneofthethreeconditions

    necessaryfordeadlock(exclusivecontrol,hold-wait,andnopreemption).Thismethodisusually

    referredtoasdeadlockprevention,unlessitsprimaryaimistoavoiddeadlock

    byusinginformationabouttheprocessesfutureintentionsregardingresource

  • 8/2/2019 10.1.1.72.4304_DeadLock

    33/320

    requirements.Atotallydi erentstrategyinterrogatestheprocess/resourcerelationshipsfromtimetotimeinordertoidentifytheexistenceofadeadlock.Thislatter

    methodpresumesthatthesystemcansubsequentlydosomethingabouttheproblem.

    Detectiontechniques.Thesetechniquesassumethatallresourcerequestswillbegranted

    eventually.Aperiodicallyinvokedalgorithmexaminescurrentresourceallocationsand

  • 8/2/2019 10.1.1.72.4304_DeadLock

    34/320

    outstandingrequeststodetermineifanyprocessesorresourcesaredeadlocked.Ifadeadlockisdiscovered,thesystemmustrecoverasgracefully

    4

  • 8/2/2019 10.1.1.72.4304_DeadLock

    35/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    36/320

    Sometimes,usingdetectionprinciplese ectivelyisdi cult|forexample,whenpreemptionofresourcessuchastapedrivesmightincurunacceptableoverhead.Nevertheless,detectiontechniques

    havesomeadvantagessincetheschemesareinvokedintermittentlyandonlyessentialpreemptions

    needbeperformed.

    Inthedatabasecontext,detectionmethodsrelyon

    themanagementsystemtoabort,rollbacktoaprevious

  • 8/2/2019 10.1.1.72.4304_DeadLock

    37/320

    checkpoint,andrestartatleastoneprocesstobreakthedeadlock.Here,theproblemofrollbackandrecoveryassumesgreatimportancefromtheviewpoint

    ofmaintainingdatabaseconsistency.

    Preventionmechanisms.Preventionistheprocessof

    constrainingsystemuserssothatrequestsleadingtodeadlockneveroccur.Mostproposals

    forpreventionrequireeachprocesstospecifyallneededresources

  • 8/2/2019 10.1.1.72.4304_DeadLock

    38/320

    beforetransactionsbegin.Deadlockscanbepreventedinseveralways,includingrequestingallresourcesatonce,preemptingresourcesheld,andorderingresources.

    Thesimplestwayofpreventingdeadlockistooutlawconcurrency,butthisleads

    toverypoorresourceutilizationandisnotconsistentwithcurrentsystemdesign

    philosophies.Anothermethodrequiresthatallresourcesbeacquiredbefore

  • 8/2/2019 10.1.1.72.4304_DeadLock

    39/320

    processingstarts.Suchaschemeisine cient,sinceresourcesheldmaybeidleforprolongedperiods,butworkswellforprocesseswhichperforma

    singleburstofactivity,suchasinput/outputdrivers,sincetheresourcecanbe

    releasedimmediatelyaftereachuse.Forprocesseswithuctuatingrequirements,themethodcan

    beimpractical.Inadatabaseenvironment,itmaybeimpossible

  • 8/2/2019 10.1.1.72.4304_DeadLock

    40/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    41/320

    needsmoremainmemorythaniscurrentlyavailable,itbecomesblocked.Subsequentlytheprocessisswappedtosecondarystoragebypreemptingitsmemoryfor

    usebyanactiveprocess.Theblockedprocessisswappedbackonlywhen

    theentire,largerquantityofmemoryisavailable.Forsomepeculiarsituationsin

    databasesystems,thisuseofpreemptiontopreventdeadlocksis

  • 8/2/2019 10.1.1.72.4304_DeadLock

    42/320

    subjecttocyclicrestart,inwhichtwoormoreprocessesloopbycontinuallyblocking,aborting,andrestartingeachother.

    5

  • 8/2/2019 10.1.1.72.4304_DeadLock

    43/320

    P1P2++ + + ++t/ / / /::::::P 2P1r w r w0 t1/ / / // / / /

    P 2+ + +P2+:r+w+ + + +:: ::

    t2rP 1+ +r+r wr ww:A A D D A A D D BB B B B

    P1r D D r A wr BFigure 3. Cyclic restart.STARTS RESTARTS WAITSSTARTS WAITS RESTARTSREPETITIONTIME= PROCESS INITIATION OR RESTART

  • 8/2/2019 10.1.1.72.4304_DeadLock

    44/320

    + = DATABASE READ OR WRITE OPERATION/ = PERIOD OF PROCESS BLOCKConsider two processes P1 and P2, checkpointed and starting at time t0, as shownin Figure 3. In the

  • 8/2/2019 10.1.1.72.4304_DeadLock

    45/320

    rst phase, processes P1 and P2 issue update requests fwA, wDg and fwBg, respectively, on entities fA, Dgand fBg. At time t1 > t0 process P1 requests access to entity B(rB) and gets blocked. Shortly afterwards,P2 requests access to D(rD), resulting in a deadlock. The deadlock arbitrator selects the blocked process P1for abortion and restart. In this case, the nature of the transactions are suchthat the situation at time t1is repeated at time t2. Such a cycle tends to be self-synchronizing, continuinginde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    46/320

    nitely, notwithstandingminor system environment variations in timing.Havender5 developed a set of approaches which excludes a priori the possibilityof deadlock by restrictingthe way in which resources can be requested. In one approach, all the required resources must be requestedand granted before the process can proceed. In a second strategy, when a processholding certain resources isdenied a further request, the process must be capable of releasing all of its original resources and rerequestingthem, together with the additional ones.A more sophisticated form of prevention employs a unique ordering of the resources:5 A request for aspeci

  • 8/2/2019 10.1.1.72.4304_DeadLock

    47/320

    c resource is met only if all resources lower in rank, which are needed in the future, have also beenallocated. By this means, circular chains of blocked processes cannot occur, since each process requestsresources in the same orderly way. The feasibility of enforcing resource ordering by compile-time checksis a major advantage of the scheme. Restrictions on the allowable sequences of process requests forceknowledgeable use of the ordering rule. A process may request and hold some units of a resource rather earlyin the processing stage, in which case a later incremental request for the sameresource may be disallowed bythe ordering rule. Consequent recovery is possible only by preempting all the resources held by the process.In a database environment with data-driven processes ofuctuating needs, it is often impossible to orderthe data resources (records, entities, or

  • 8/2/2019 10.1.1.72.4304_DeadLock

    48/320

    elds), so this resource ordering method is seldom applicable.Avoidance schemes. In avoidance schemes, a resource request is granted only if at least one wayremains for all processes to complete execution. One basic scheme, referred to as the \banker's algorithm; "6manages multiple units of a single resource by requiring that the processes specify their total resource needsat initiation time. Furthermore, each process acquires or returns resource unitsone at a time. The algorithmdenies a request by any process whose remaining needs are in excess of the available resources. E ectively,6

  • 8/2/2019 10.1.1.72.4304_DeadLock

    49/320

    theschemeprojectsdetectionintothefuturetokeepthesystemfromcommittingitselftoanallocationwhicheventuallyleadstodeadlock.

    Habermandevelopeda\maximumclaimsstrategy"7tocontrolthefutureresourcerequirements

    foreachprocess.Thisgeneralizationofthebanker'salgorithmisapracticalexample

    ofavoidancebutrequiresquantityinformation,intheformof

  • 8/2/2019 10.1.1.72.4304_DeadLock

    50/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    51/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    52/320

    referredtoasan\indi erentor\nostrategyapproach.Ithasasuper

  • 8/2/2019 10.1.1.72.4304_DeadLock

    53/320

    cialadvantageofsavingprocessortimeandspaceotherwiserequiredfordetection,prevention,oravoidancemethods.However,theonusofrecognizingdeadlocksisborne

    byeitheracomputeroperatordiscoveringblockedprocessesorauserwaitingfor

    ananswer,andignoringdeadlockshasdisastrouse ectsontheconsistencyofdata

    inanydatabasesystem.

    Approachescompared.Empiricalobservations

  • 8/2/2019 10.1.1.72.4304_DeadLock

    54/320

    havesuggestedthatdeadlockpreventionmechanismstendtoundercommitresourceswhiledetectiontechniquesgiveawayresourcessofreelythatprolongedblockingsituationsarisefrequently.

    Avoidanceschemesfallsomewhereinbetween.However,obtaininggoodupperboundsisa

    severetechnicaldi culty,sinceotherwiseresourcesareusedine ciently.

    Ina

    heavilyloadedsystem,Havender'spreventionmethodsprovideveryfewsafe

  • 8/2/2019 10.1.1.72.4304_DeadLock

    55/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    56/320

    preventionandavoidancecases,recoveryfromasystemimplementationerrorneedsarollbackmechanism.

    Table1summarizesthebasicdeadlockdetection,prevention,

    andavoidancetechniquesforoperatingsystems,alongwiththeirprimarymeritsandde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    57/320

    ciencies.

    Graph-theoreticmodelsfordeadlockdetection

    Inconsideringthedeadlockproblem,therepresentationofprocessinteractionsduringresourceallocationphases

    isimportant.Processesincomputersystemscanbedynamicinthesensethat

    oneprocessmaycreateanother.Processesaresaidtointeractexplicitlywhenthey

    communicateamongthemselves.Processinteractionsresultingfromcompetitionfor

  • 8/2/2019 10.1.1.72.4304_DeadLock

    58/320

    accesstophysicalobjectsaretermedimplicit.Blockingofprocessesmaybecausedbyeithertypeofinteraction.Holt8hasproposedthedistinctionof

    reusableandconsumableresourcestomodelimplicitandexplicitinterations,respectively.Emphasizedis

    thefactthatanarbitrarynumberofprocessescanwaitforaconsumable

    resource,whereasonlya

  • 8/2/2019 10.1.1.72.4304_DeadLock

    59/320

    xednumberofreusableunitsareavailable.

    Thephysicaldevicesofacomputersystem,suchastapedrives,disks,memory,andI/O

    channels,arereusableresources.Thereisalwaysa

  • 8/2/2019 10.1.1.72.4304_DeadLock

    60/320

    xedtotalnumberofunitsoftheseresourcesinasystem.Anyunitofaparticularresourcecanbeheldbyoneprocessat

    atime.Thus,eachunitofaresourceiseitherfreeforallocation

    orisheldbyaprocess.Theallocationstrategiesspecifytheunitsize

    oftheresource.For

    7

  • 8/2/2019 10.1.1.72.4304_DeadLock

    61/320

    Table1.Summaryofdetection,prevention,andavoidanceapproachesforoperatingsystems.

    PRINCIPLERESOURCEALLOCATIONPOLICYDIFFERENTSCHEMESMAJORADVANTAGESMAJOR

    DISADVANTAGESDETECTIONVeryliberal;requestedresourcesaregrantedwherepossible.Invokeperiodicallyto

    testfordeadlock.

    Neverdelaysprocessinitiation.

    Facilitateson-linehandling.

    Inherentpreemptionlosses.PREVENTIONConservative;undercommitsresources.Requestingallresources

  • 8/2/2019 10.1.1.72.4304_DeadLock

    62/320

    atonce.Preemption.Resourceordering.

    Workswellforprocessesthatperformasingleburstofactivity.

    Nopreemptionnecessary.

    Convenientwhen

    appliedtoresourceswhosestatecanbesavedandrestoredeasily.

    Feasible

    toenforceviacompile-timechecks.

    Needsnorun-timecomputationsinceproblemis

    solvedinsystemdesign.

    Ine cient.

    Delaysprocessinitiation.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    63/320

    Preemptsmoreoftenthannecessary.

    Subjecttocyclicrestart.

    Preemptswithoutmuchuse.

    Disallowsincrementalresourcerequests.AVOIDANCESelectsmidway

    betweenthatofdetectionandprevention.Manipulateto

  • 8/2/2019 10.1.1.72.4304_DeadLock

    64/320

    ndatleastonesafepath.

    Nopreemptionnecessary.

    Futureresourcerequirementsmustbeknown.

    Processescanbeblockedforlong

    periods.

    example,memorymaybeallocatedbypages,disksmaybe

    heldinunitsoftracks,cylinders,orentiredisks,anddatamaybe

    assignedasrecords,

  • 8/2/2019 10.1.1.72.4304_DeadLock

    65/320

    elds,entities,or

  • 8/2/2019 10.1.1.72.4304_DeadLock

    66/320

    les.

    Messagetextfromoperators,externalinterrupts,interprocesscommunications,addcardimagesproducedbyacardreaderareexamplesofconsumableresources.

    Typically,thetotalnumberofresourceunitsisnot

  • 8/2/2019 10.1.1.72.4304_DeadLock

    67/320

    xed.Whenaconsumableresourceisacquiredbyaprocess,itceasestoexist.Aprocesswhichcreates(produces)aconsumableresourcemayrelease

    anynumberofunitsatatimeandmustbetreatedasif

    itwereholdingtheresource.Consumableresourcesarecreatedandreleasedbya

    producingprocessandarerequested,acquired,andusedbyother

  • 8/2/2019 10.1.1.72.4304_DeadLock

    68/320

    processes.Ontheotherhand,reusableresourcesareassignedbytheresourcemanagertorequestingprocesses,whicheventuallyreturnthemtothemanager.

    Manyphysicalresourcespermitonlyexclusiveusebyoneprocessata

    time,butothers,likedataresourcesandread-onlyprograms,mayallowshareduse

    byseveralprocesses.Anotherpropertyofaresourceisits

  • 8/2/2019 10.1.1.72.4304_DeadLock

    69/320

    abilitytoallowpreemption.Someresourcesmaybetakenbackbythesystemwithoutanyactionbythe

    8

  • 8/2/2019 10.1.1.72.4304_DeadLock

    70/320

    RRRePePePeP1231132esses: shared access.e: exclusive access.RRR

    ePePePeP1231132es

    ses: shared access.e: exclusive access.Figure4.StategraphforExampleA.

    process.Suchaprocessistheneitheraborted,rolledback

  • 8/2/2019 10.1.1.72.4304_DeadLock

    71/320

    (ifnecessary)andrestarted,orforcedtorerequestandthuswaitforthepreemptedresource.Thecostofabortingorrestartingtheprocessaccounts

    forthepreemptionlosses.

    Incertaincases,itispossibleto

    suspendaprocessandpreemptoneofitsresources,yetpreservethecurrent

    statesoftheprocessanditsuseofthatresource

  • 8/2/2019 10.1.1.72.4304_DeadLock

    72/320

    forlaterresumption.Typically,suchresumptiondoesnotloseprocessingtimealreadyspent.Forexample:

    CPUinterrupts,inwhichtheresource

    preemptedistheCPUandtheinformationthatmustbepreservedforlater

    restorationisthestatusoftheprocess(forexample,registersandthe\program

    statusword"),and

    swapping,inwhichthepreemptedresource

  • 8/2/2019 10.1.1.72.4304_DeadLock

    73/320

    istheprimarymemoryandbackupisprovidedinsecondarystorage.Whenthesystemhasdi erentresourcetypesandmorethanoneresourceof

    thesametype,thecomplexityofthedeadlockproblemincreases.Attemptstomodel

    andformalizetheproblemhaveresultedintwomajor

    8;9

    proposals.Graph-theoreticmodelsoftheprocessinteractionshavebeendeveloped,

  • 8/2/2019 10.1.1.72.4304_DeadLock

    74/320

    anddeadlockshavebeenexpressedpreciselyintermsofgraphtopologies.

    Stategraphmodel.Therelationshipsbetweenasetofprocessesand

    asetofdistinctresourcesinusebytheseprocessescanbedescribed

    byastategraph:9Thisisadirectedgraphwhosenodescorrespondto

    theresourcesandwhoseedgesarede

  • 8/2/2019 10.1.1.72.4304_DeadLock

    75/320

    nedsothatifsomeprocessPhasaccesstoresourceRiandiswaitingforaccesstoresourceRj,thenthereexists

    anedgedirectedfromnodeRitonodeRj.

    Example

    A.LetfP1;P2;P3}andfR1;R2;R3}betheprocessesandresourcesinasystem,

    respectively.LetR1beheldforsharedaccessbyboth

  • 8/2/2019 10.1.1.72.4304_DeadLock

    76/320

    P1andP2,andletP3bewaitingforexclusiveaccesstoR1.AssumethatR2andR3areheldforexclusiveaccessby

    P3andP1,respectively,whileP1andP2waitforexclusiveaccess.The

    processinteractionsherecanberepresentedbythestategraphshowninFigure

    4.Forclarityandbetterunderstanding,wehavelabeledthe

  • 8/2/2019 10.1.1.72.4304_DeadLock

    77/320

    edgesinthestategraph.Forinstance,theedgedirectedtoR3fromR1islabeledeP2sindicatingthatP2holdsR1forshared

    (s)accessandawaitsexclusive(e)accesstoR3.Theexistenceofa

    circuitinthestategraphmeansthatadeadlockexists.Acircuitis

    acloseddirectedpathlinkingasubsetofthenodes

  • 8/2/2019 10.1.1.72.4304_DeadLock

    78/320

    inthegraph.ThusthepathR3R2R1R3linkingthreenodes,showsthatthreeprocessesareinvolvedindeadlock.

    Inthegeneralcase,

    involvingmultiple-unitresources,thestategraphjustde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    79/320

    nedisinappropriate.Co man9hasproposedthattheresourcesbepartitionedintodi erenttypes,insuchawaythatresourcesof

    9

  • 8/2/2019 10.1.1.72.4304_DeadLock

    80/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    81/320

    amethodneedsamoreelaboratestatedescriptionmechanism,supplementedwith\allocationand\requestmatricesandan"availableresourcesvector.Adetectionalgorithmmust

    bedesignedwhichusesthesedatastructurestodiscoveradeadlockbysimply

    investigatingeverypossibleallocationsequencefortheprocessesthatremain.

    General

    resourcegraphmodel.Holt'smodel8ofasystemofinteracting

  • 8/2/2019 10.1.1.72.4304_DeadLock

    82/320

    processesprovidesaversatilerepresentationforresourcemanagement.Theapproachischaracterizedbytheuseofa\generalresourcesystemwhichmodelsreusableas

    wellasconsumableresources.Ageneralresourcegraphisde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    83/320

    nedasa\bipartitegraph"10whosenodescorrespondtothesetofprocessesandthesetofresources(reusableandconsumable).Anavailableunits

    vector,whoseelementsarepositivemeasuresofthequantityavailable,isassociatedwith

    thesetofresources.Edgesdirectedfromaprocessnodetoaresource

    nodearetermedrequestedges.Edgesdirectedfromreusableand

  • 8/2/2019 10.1.1.72.4304_DeadLock

    84/320

    consumableresourcenodestoprocessesarecalledassignmentandproduceredges,respectively.Aprocessisblockedifandonlyifthenumberofrequest

    edgesfromtheprocesstoaparticularresourceexceedsthenumberofavailable

    unitsoftheresource.Aprocessisdeadlockedwhenitisimpossibleto

    gettheprocessoutoftheblockedstate.Holtintroduces

  • 8/2/2019 10.1.1.72.4304_DeadLock

    85/320

    agraphreductionmethodtocheckifaprocessisdeadlocked.Agraphreductioncorrespondstothebestsequenceofoperationsaparticularprocess

    canexecutetohelpunblockotherprocesses.Thisisachievedbydeterminingif

    thesuccessiveeliminationofallsinknodesproducespredecessorswhicharealsosinks.

    Asinknodeisonewithnoedgesemanatingfrom

  • 8/2/2019 10.1.1.72.4304_DeadLock

    86/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    87/320

    theprocesswasnotdeadlocked.

    Itcanbeshownthatforageneralresourcegraphinwhichallprocesseshavingrequestsare

    blocked,theexistenceofacircuitisanecessaryandsu cientconditionfor

    deadlock.AsimpleillustrationofageneralresourcegraphcorrespondingtoExampleA

    isshowninFigure5.Itisevidentthatthe

  • 8/2/2019 10.1.1.72.4304_DeadLock

    88/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    89/320

    nallyP1waitsforP3toreleaseR2.Forthemultipleunitsofresourcecase,aweightisassociatedwitheachallocationedgeto

    representthenumberofunitsheldbytheresource.

    Deadlocksin

    databases

    Manydi erentdeadlock-handlingalgorithmsandapproachesdevelopedforoperatingsystems

    havebeenpresented.Databaseanddistributeddatabasesystems,however,pose

  • 8/2/2019 10.1.1.72.4304_DeadLock

    90/320

    uniqueproblemsoftheirown.Theconcernisnotonlywithavoidingdeadlocksituationsbutalsowithprotectingagainstdatabaseinconsistencies.

    Theschemesforhandlingdeadlockinoperatingsystems,discussedabove,formthebasis

    fordatabasecontrol,butthenatureofdatabaseaccessissuchthatprevention

    andavoidancemethodsarelessfeasible.Basically,toomanydatabase

  • 8/2/2019 10.1.1.72.4304_DeadLock

    91/320

    applicationsaredata-driven|thatis,thenextactionisbasedonthevalueofthecurrentitemretrieved.Thusdetectionmethodsandassociatedrecoveryschemes

    whichselectresources

    9

    forpreemptiononabasisof

    theirrecoverycostbecomeimportant.Theserecoverytechniquesaredesignedtoavoidpreemption

    ofresourceswithhighinherentlosses.

    10

  • 8/2/2019 10.1.1.72.4304_DeadLock

    92/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    93/320

    PPRRR11223e esseP3e ePPRRR11223

    e esseP3e ePPRRjr

    isResource-process active edge.Process-resource wait edge.

    e: Exclusive access.s: Shared access.Figure5.Generalresourcegraphfor

    ExampleA.

    Databasesystems.Indatabasesystems,the

  • 8/2/2019 10.1.1.72.4304_DeadLock

    94/320

    resourceswhichprocessesmaywishtolockforexclusiveuseincludepiecesofshareddata.Veryoftentheprocessesmayissuelockrequests,such

    as\LockthepersonnelrecordsofallemployeesintheSystemsProgrammingDept.,

    forwhichthelockingcriteriondependsondatavalues.Thedi cultiesintroducedby

    thismethodarenormallyabsentinanoperatingsystemenvironment.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    95/320

    Inaddition,aparticulardataresourcemaybedescribedinmorethanoneway,orthenatureofadataresourcemaybealtered

    byaprocessoperatingonit.Locksmaybeinterdependentinthesense

    thatfurtherlocksmayhavetoberequesteddependingonthe

  • 8/2/2019 10.1.1.72.4304_DeadLock

    96/320

    rstlock.Becauseofthesedi cultiesinanticipatingfuturerequirements,manyconventionalapproachestoresourcemanagementinoperatingsystemsaredi cultorimpossiblein

    thedatabaseenvironment.Inthecaseofpreemptionofadataresource,the

    necessityofmaintaininguniformlycorrectdatainthesystemdictatestheabortion,rollback,

    andrestartingofoneormoreprocesses.Thisisgenerally

  • 8/2/2019 10.1.1.72.4304_DeadLock

    97/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    98/320

    11

    information.Adirectededgeexistsbetweentwonodeswheneveronenodecontainstheaddressoftheother.Suchadatabaseis

    assumedtobeaccessedbyasetofroutinescalledprimitives.Underconcurrent

    operation,twoormoreprimitivesmayconictwitheachotherwhileaccessinga

    node.Toovercometheseconictsaprocedurecalledthe"walking

  • 8/2/2019 10.1.1.72.4304_DeadLock

    99/320

    algorithmwasformulated.Itrequiresaprimitiveto(1)setthelockofthenextnodeitwishestoaccessbeforeunlockingthenode

    itiscurrentlyaccessingand(2)keepanodelockedonlyforthe

    durationofitsaccess.Thewalkingalgorithmavoidsthepossibilityoftwoprimit

    iveswritingthesamenodesimultaneously.Also,thealgorithmrequires

  • 8/2/2019 10.1.1.72.4304_DeadLock

    100/320

    thatanodebeunlockedandallitsdatabasepointerserasedbeforeitcanbedeletedandreturnedtothefreelist.Thisovercomes

    aproblemthatcouldariseifaprimitiveerasedapointerfroma

    nodeimmediatelyafteritwasreadbysomeotherprimitive.Ifsucherasure

    wereallowed,subsequentactionsbythereadingprimitivewhichdepend

  • 8/2/2019 10.1.1.72.4304_DeadLock

    101/320

    onthatpointermightbeinvalid.

    TheCodasyl16approachtodatamanagementusesaLOCK-UNLOCKmechanismtoenableincremental

    11

  • 8/2/2019 10.1.1.72.4304_DeadLock

    102/320

    allocationofdataresourcestoprocesses.Thestatusofallaccessestothedatabaseismaintainedinanaccessstategraph;12adirected

    graphwhosenodescorrespondtotheunionofthesetofactiveprocesses

    andthesetofallocatabledataelements.Thesetofedgesisreferred

    toasthelocklist,andeachelementrepresentsan

  • 8/2/2019 10.1.1.72.4304_DeadLock

    103/320

    edgeemanatingfromtheactiveprocessnodeandterminatingatthedataelementallocatedtothatprocess.Thebasicmechanismoftheschemeis

    tomodeleachoperation,LOCK,UNLOCK,ALLOCATE,andDEALLOCATE.Forinstance,alock

    actioncanberepresentedbymappingtheaccessstategraphbeforeaprocess

    wasallowedtolockadataelementontotheaccess

  • 8/2/2019 10.1.1.72.4304_DeadLock

    104/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    105/320

    cannotwaitformorethanoneresourceatatime.

    Oneproposedtechnique17modi

  • 8/2/2019 10.1.1.72.4304_DeadLock

    106/320

    esandcombinesthefollowingsteps:

    (1)trytopreclaimneededresources;(2)preemptdataresourceswhenpreclaimingleadstoadeadlock;

    and(3)imposeapresequencingschemeforprocessesbytimestamping,toavoid

    deadlockduetoinde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    107/320

    nitedelay.Themethodrequireseachprocesstolockallofitsdataresourcesduringaseizephasebeforestartingtheexecutionphase.Competition

    forresourcesthereforeoccursonlyduringseizephases.Backingupaprocessto

    thestartofthisphaseiseasy,sincetherearenorepercussionsfrom

    preemptingaresource,eventhoughithasbeententativelyallocated

  • 8/2/2019 10.1.1.72.4304_DeadLock

    108/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    109/320

    nitedelay,anageindicatorisattachedtoblockedprocesses,foruseasaprioritybythescheduler.Thusthemethodisdeadlock-free.

    One-levelandtwo-levellockoutmechanisms14havealsobeenconsideredforsynchronizingdatabase

    access.Intheone-levellockoutscheme,sharedaccess(byreaders)tothe

    databaseisallowedatanytime,regardlessoftheallocation

  • 8/2/2019 10.1.1.72.4304_DeadLock

    110/320

    state.Conversely,writersarerequiredtolockthedataresourcesbeforealteringthem.Asinotherschemes,thepresenceofacircuitinthe

    stategraphisanecessaryandsu cientconditionfordeadlock.Schlageterprovidesan

    algorithmfordetectingdeadlockbytraversingthegraphfromablockedprocessnode,

    inanattempttoreturntothatblockednode.In

  • 8/2/2019 10.1.1.72.4304_DeadLock

    111/320

    thetwo-levellockoutscheme,readersaresplitintotwoclasses:thosewhichareinsensitivetoconcurrentupdatesandthosewhichpreventwritersfromconcurrently

    accessingthedata.ThisisimplementedbyusingprimitivesLOCKR(read)andLOCKW

    (write).DatalockedbyLOCKRcanbeaccessedbyanyreader.Datalocked

    byLOCKWcanbeaccessedonlybyreaderswhichdo

  • 8/2/2019 10.1.1.72.4304_DeadLock

    112/320

    notneedtobeprotectedagainstchangesofdata.Underthetwo-levellockoutmechanism,startingatablockedprocessnodeandtraversingpathsto

    detectdeadlocksisnolongersimple,becausearesourcemaybeheldby

    severalprocessessimultaneouslyandeachofthosemayberegardedasblockingany

    waitingprocess.

    Theschemeproposedfordeadlockavoidance

  • 8/2/2019 10.1.1.72.4304_DeadLock

    113/320

    indatabasesystems15requirestheprocessestopre-declaretheiranticipatedresourcerequirements,withthesystemgrantingonlysaferequests.Thealgorithmistailoredto

    theneedsofdatabasesystems,unlikeotherapproaches.5;8Aseriesoftime-varying

    graphrepresentationsarede

  • 8/2/2019 10.1.1.72.4304_DeadLock

    114/320

    nedfordatabaseinteractions.A\holds-claimsgraphrepresentsonlythoseprocessesthatarecurrentlymakingaclaimonsomecommonsystemresources.A\claims-claims

    graphrepresentstheprocesseswhicharepotentiallycapableofdenyingresourcestoone

    another,theirclaimsbeingincontention.A\holds-holdsgraphrepresentstheallocationstatus

    ofthesystem.Adeadlockexistsifandonlyif

  • 8/2/2019 10.1.1.72.4304_DeadLock

    115/320

    thereisacircuitintheholds-holdsgraph,whereasadeadlockcanbeavoidedifandonlyiftheholds-claims

    12

  • 8/2/2019 10.1.1.72.4304_DeadLock

    116/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    117/320

    nitedelayisnotentirelyeliminated,itisreducedbythestrategyofgrantingrequestsinanincrementalway.

    Distributeddatabases.There

    isagrowingbodyofworkondistributeddatabases,butearlyattemptsto

    handledeadlockshadpracticaldrawbacks.Thesalientfeaturesofsomemethodswillbe

    reviewedhere,whileanon-lineapproach17willbedealtwith

  • 8/2/2019 10.1.1.72.4304_DeadLock

    118/320

    inthenextsection.

    Themaincharacteristicofdistributedcomputingisthatoperatingsystemsmustcontendwithmoreautonomousbehavior,thusaggravating

    thecontrolproblem.Presenceofappreciabletime-lagsrenderscoordinationofthevariouscontrollers

    inthesystemmuchmoredi cult.Moreover,ingeographicallydistributeddatabasesallinformation

    neededtodetectdeadlocksisnotnecessarilyavailableatany

  • 8/2/2019 10.1.1.72.4304_DeadLock

    119/320

    singleinstallation,sothedeadlockproblemissomewhatdi erent.ConsideravariationoftheexampleinFigure2,butwithtwoseparatecomputersC1

    andC2,asshowninFigure6.AssumethatprocessPandresource

    entityMresideatC1andthatprocessQandresourceentityN

    resideatC2.ProcessesPandQ,afterlockingand

  • 8/2/2019 10.1.1.72.4304_DeadLock

    120/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    121/320

    deadlockmaynotbedetected,oradeadlockmaybeindicatedwhereonenolongerexists.Synchronizingtheupdatesof

  • 8/2/2019 10.1.1.72.4304_DeadLock

    122/320

    leswhicharereplicatedatdi erentsitesisalsonontrivial,andabortion,rollback,andrecoverybecomeveryinvolvedandrequirecomplexinterprocesscommunication.

    Someworkonthepreventionofdeadlocksindistributeddatabaseshasbeen

    reported.Atypicalapproachrequiresthatalldataresourcesbeallocatedtothe

    processbeforeinitiation.Consequently,processinitiationisneedlesslydelayed.An

  • 8/2/2019 10.1.1.72.4304_DeadLock

    123/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    124/320

    shareddataresourceslist(conceptuallysimilartoaprocessset)toallotherprocesses

    13

  • 8/2/2019 10.1.1.72.4304_DeadLock

    125/320

    beforeitcanproceed.Thisshareddataresourceslistisdeterminedbyusingwhatiscalledaprocesspro

  • 8/2/2019 10.1.1.72.4304_DeadLock

    126/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    127/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    128/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    129/320

    theglobalnetworkstatusbyusing

  • 8/2/2019 10.1.1.72.4304_DeadLock

    130/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    131/320

    schemedegrades.Inthedistributedcontrolapproach,supportforNcomputersrequiresthetransmissionof(N-1)identicalmessagescontainingstatusandqueuesof

  • 8/2/2019 10.1.1.72.4304_DeadLock

    132/320

    les.Alsoeachinstallationreceives(N-1)di erentmessagesfromotherinstallations.

    Goldman'sdeadlockdetectionschemes22arebasedonthecreationand

    expansionofanorderedblockedprocesslist.EachprocessinanOBPLis

    waitingforaresourceheldbythenextprocessinthelist.Whenever

    anOBPListransmittedbetweeninstallations,adataresourcename

  • 8/2/2019 10.1.1.72.4304_DeadLock

    133/320

    isinsertedintotheidenti

  • 8/2/2019 10.1.1.72.4304_DeadLock

    134/320

    cationpartoftheOBPL.Thelastprocessinthelisthasaccessto,oriswaitingfor,thatresource.Intheformercase

    thestate(blockedoractive)ofthelastprocessintheOBPLmust

    bedetermined,whileinthelattercaseoneneedstoknowthestate

    oftheprocesswhichholdsthedataresource.Todetermine

  • 8/2/2019 10.1.1.72.4304_DeadLock

    135/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    136/320

    theschemerequiresthecreationandexpansionofonedi erentcopyoftheOBPLforeachreadersince,ifoneofthereadersis

    deadlocked,anyprocesswhichrequestsaccesstothatresourceisblockedforever.It

    ispossiblethatOBPLs,whileundergoingexpansion,couldbetransferred(sequentially)amongseveral

    installationsorseveraltimesbetweenthesametwoinstallationsbefore

  • 8/2/2019 10.1.1.72.4304_DeadLock

    137/320

    adeadlockisdetected.Also,OBPLscouldbecomelarge,leadingtosubstantialoverhead,especiallywhenrecordsorentities,insteadof

  • 8/2/2019 10.1.1.72.4304_DeadLock

    138/320

    les,areconsideredasdataresources.

    20;21

    OthercontributionsfromGoldman'sworkareexamplesofdeadlocksnotdetectedbytheearlier

    schemes.Thebasicawintheotherschemesistheassumptionthatallowing

    alocalprocessatonesitetowaitforalocalresourcewill

    notcauseanetwork-widedeadlock.

    Inanycase,

  • 8/2/2019 10.1.1.72.4304_DeadLock

    139/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    140/320

    Table2.Summaryofdeadlock-handlingtechniquesindistributeddatabases.

    PRINCIPLEADVANTAGESMAJORCOSTSRELEVANTREFERENCESDETECTION

    Facilitateson-lineapproach.

    Suitsdistributeddatabaseenvironmentfairlywell.

    Run-timecost.

    Highrollbackand

    restartcosts.

    Communicationcostsinmaintaininginformationfordeadlockdetection.

    Isloor

    andMarsland23

    MarslandandIsloor17

    Goldman22

    Mahmoud

  • 8/2/2019 10.1.1.72.4304_DeadLock

    141/320

    andRiordon21

    Chandra,Howe,andKarp20PREVENTION

    Rollbackandrestartisnotnecessary.

    Intheabsenceofsoftwareerrors,consistencyof

    databaseisguaranteed.

    Costsofwaitingforhighlydata-drivenprocesses.

    Communication

    costsintransmittingtheadvanceinformationonfuturerequests.

    Maryanski19

    Chu

    andOhlmacher18AVOIDANCE

    Minimaluseofrollbackandrestart.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    142/320

    Dataresourceallocationpolicyismidwaybetweenthatofhighlyconservativepreventionandveryliberaldetectionprinciples.

    Costsofwaitingprocessesand

    run-timecosts.

    Moderaterollbackcost.

    Communicationcostsoftransmittingfuturedata

    resourceallocationrequests.

    ChuandOhlmacher18

    On-linedetectionindistributed

    databases

    17;23

    Theconceptofon-linedetection

  • 8/2/2019 10.1.1.72.4304_DeadLock

    143/320

    ofdeadlocksinadistributeddatabasehasbeenintroduced.Itisde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    144/320

    nedtobetherecognitionofdeadlockasrequestsaremadeorgranted,bybothlocalandremoteresourceallocators,withoutthenecessityof

    furthercommunicationamonginstallations.Existingalgorithms20..22fordeadlockdetectionindistributeddatabases,because

    theywerenotdesignedforon-linedetection,haveseveral-problemsforon-lineuse:

    (1)Foreveryrequest,grantedornot,existingalgorithms

  • 8/2/2019 10.1.1.72.4304_DeadLock

    145/320

    needtoobtaintheglobalnetworkstatusbysimultaneoustransmissionofeachinstallation'sstatus,leadingtoheavycommunicationtra c.(2)Sincethistra cresults

    incommunicationdelays,anewdeadlockmaygoundetectedoranapparentdeadlock

    maynolongerexist.(3)Afterobtainingthecompletenetworkstatus,thealgorithms

    stillhavetoperformdeadlockdetectioncomputations.8

    The

  • 8/2/2019 10.1.1.72.4304_DeadLock

    146/320

    useofareachablesetmayovercometheseproblemstosomeextent.Thus,inasystemgraphrepresentingprocessinteractions,thesetofall

    nodestraversedbyadirectedpathfromagivennodeconstitutesitsreachable

    set,andaprocessisdeadlockedifandonlyifthecorrespondingprocess

    nodebelongstoitsownreachableset.23Maintainingreachable

  • 8/2/2019 10.1.1.72.4304_DeadLock

    147/320

    setsbyincrementalupdates,asresourcesareallocatedandfreed

    15

  • 8/2/2019 10.1.1.72.4304_DeadLock

    148/320

    RRRRPP PP2 21 13 34 4eeseeC1 C2sRRRRPP PP

    2 21 13 34 4eeseeC1 C2sRPi j

    Resource-process access edge.RP s rProcess-resource wait edge.

    e: Exclusive access.s: Shared access.Figure7.On-linedetection.

    ateachinstallation,enableslocalrecognitionofdeadlocks,andallows

  • 8/2/2019 10.1.1.72.4304_DeadLock

    149/320

    theallocationdecisiontobemadewithoutfurthermessages.

    Theon-lineapproachtodeadlockhandlingeliminatestheneedforperiodictransferof

    lengthymessagesamongthecomputersinthenetworktoascertainthedeadlockstatus

    ofthesystem.Becausecommunicationdelaysarenegligible,themethodreducesthetime

    intervalduringwhichdeadlocksgoundetected.

    Consider,for

  • 8/2/2019 10.1.1.72.4304_DeadLock

    150/320

    instance,Figure7representingcomputersystemsC1andC2.LetprocessesfP1;P2}andresourcesfR1;R2}resideonC1andsimilarlyprocessesfP3;P4}andresources

    fR3;R4}resideonC2.ForsimplicityassumethateachresourceRiisheld

    byprocessPiforexclusiveaccess(foralli),thatP4iswaiting

    foraccesstoR1,andthatP2iswaitingfor

  • 8/2/2019 10.1.1.72.4304_DeadLock

    151/320

    R3.Atanyinstant(say,t0)bothC1andC2possessupdatedreachablesetsforR2andR4,namelyfP2;R3;P3}andfP4;R1;P1g,respectively.Subsequently,

    letP1andP3requestaccesstoR2andR4,respectively.Deadlockis

    nowinevitableandwillberecognizedupontheintroductionoftheprocess-resourcewait

    edgesfromP3toR4andP1toR2.At

  • 8/2/2019 10.1.1.72.4304_DeadLock

    152/320

    theinstantt1,neithercomputerdetectstrouble,butwhenC1andC2receivetheinformationontheadditionoftheedgesateachother's

    installation,thedeadlockisdetectedatbothsitesasthereachablesetsare

    updated.TheessenceofthisexampleisthatrequestsbyP1forR2

    andP3forR4occurwithinthesametimeframe.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    153/320

    Thus,nomatterwhatdetectionisused,theallocationwilloccurbecauseneithercomputercanbeawareoftheactivitiesoftheother.Under

    thesecircumstances,apreemptionmechanismisnecessaryinordertorecovercontrolof

    thesystem.ItwasjustsuchasituationasthiswhichallowedGoldman

    todeducethatothermethods20;21fordeadlockdetectionindistributed

  • 8/2/2019 10.1.1.72.4304_DeadLock

    154/320

    systemswereawed.

    Themotivationforon-linedetectionisaconsequenceofseveralfactors.Aslargeintegrateddatabasesrespondtomoreusers,

    thepossibilityofdeadlocksincreasesrapidly.Furthermore,thearrivalofdistributedprocessingon

    thesceneenhancestheneedforimmediatedeadlockdetection.Inadistributedenvironment,

    anydelayinthedetectionofdeadlockshasadversee ects

  • 8/2/2019 10.1.1.72.4304_DeadLock

    155/320

    ondatabaseconsistency.

    Severalaspectsofon-linedetectionmaybeconsideredforthefollowingcompletesetofprocess-resourceinteractions:

    (1)

    anewprocessentersthesystem;(2)anewdataresourceisaccessed;

    16

  • 8/2/2019 10.1.1.72.4304_DeadLock

    156/320

    21PRRP R PP R2 4 41 3 3s ee e ee es21PRRP R PP R2 4 41 3 3s ee e ee ese: Exclusive access.

    s: Shared access.Figure8.SystemgraphforExampleB.

    (3)aprocess

    runstocompletionandreleasesallthedataresourcesheld;(4)aprocess

    inthesystemrequestsaccesstoadataresourceheld

  • 8/2/2019 10.1.1.72.4304_DeadLock

    157/320

    byanotherprocess;and(5)adataresourceheldbyaprocessispreemptedfromit.Incases(1)and(2),adeadlock-freesystem

    remainsdeadlock-free.Forcase(3),allocationdecisionsforreleaseddataresourceswithoutany

    waiting-accessrequests,orwithasinglewaiting-accessrequest,donotleadtodeadlock.

    However,anallocationdecisionforareleaseddataresourcewith

  • 8/2/2019 10.1.1.72.4304_DeadLock

    158/320

    multiplewaiting-accessrequestscanleadtopotentialdeadlocksasshowninExampleB.Evenso,atleastonesafeallocationexists.17

    ExampleB.ConsiderprocessesP1,P2,P3,andP4whichholddataresources

    R1,R2,R3,andR4,respectively,forexclusiveuse.Letusassumethat

    P1iswaitingforsharedaccesstoR3,P2for

  • 8/2/2019 10.1.1.72.4304_DeadLock

    159/320

    R1,andP4forexclusiveuseofR2andR3.SupposethatprocessP3runstocompletionandreleasesresourceR3.R3hastwo

    waiting-accessrequestsfromP4andP1.AssumethatP4issueditsrequestbefore

    P1did.IftheallocationofR3toP4isdoneina

    FIFOmanner,thenprocessesP1,P2,andP4willbe

  • 8/2/2019 10.1.1.72.4304_DeadLock

    160/320

    deadlocked.ItisobviouslymoreadvantageoustomaketheallocationofR3toP1,andletP1runtocompletion,thantomakethe

    allocationofR3toP4andbedeadlocked.Anecessaryandsu cientcondition,

    basedonreachablesets,hasbeenderived23torecognizesituationsinwhichprocesses

    havemorethanoneoutstandingrequest,andtoavoiddeadlock

  • 8/2/2019 10.1.1.72.4304_DeadLock

    161/320

    accordingly.InFigure8itisprocessP4whichhaswaiting-accessrequestsforbothR2andR3.

    Marsland17showsthat,inthe

    caseofadeadlock-freesystemwithmultipleprocesseswaitingforaccesstoa

    releaseddataresource,thereexistsatleastoneprocesssuchthatanallocation

    madetothisprocessmaintainsthesystemdeadlock-free.Furtherimprovement

  • 8/2/2019 10.1.1.72.4304_DeadLock

    162/320

    maybepossiblebyallocatingtheresourcetoasafeprocesswhichhasminimumwaiting-accessrequestsonotherdataresources.Inbatchoperatingsystems,

    aprocessistypicallyallowedtohavemorethanoneoutstandingrequestat

    atime;however,ifthesystemisunabletosatisfyalltheoutstanding

    requestsatonce,theprocessisrequiredtodropthem.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    163/320

    8ThisinturnrulesouttheoccurrenceofasituationanalogoustothatdescribedinExampleB.Consequently,earlyresearchersofthedeadlock

    problemindatabasesalsodisallowedmultipleoutstandingrequests.Sincedatabaserequestsaredata-driven

    andcontent-based,thepossibilityofmultipleoutstandingrequestsishigh,andsothe

    on-lineapproachisuseful.

    Incase(4),honoring

  • 8/2/2019 10.1.1.72.4304_DeadLock

    164/320

    therequestmayleadtoadeadlock,whileincase(5)anattemptisbeingmadetobreakdeadlockthroughpreemptionofaresource.

    Forallthesecasesalgorithmsareavailableforupdating

    17;23

    thereachablesetsforeveryedgeaddedordeletedinthesystemgraph.

    Besidesitslowlevelofcommunicationactivity,theon-lineapproach

  • 8/2/2019 10.1.1.72.4304_DeadLock

    165/320

    hasthefollowingmajoradvantages:

    17

  • 8/2/2019 10.1.1.72.4304_DeadLock

    166/320

    Aprocessisallowedtohaveanynumberofoutstandingrequests.

    Whenanumberofreadersshareadataresource,no

    specialtreatmentisneeded,unlikeschemes22

    whichrequirethatadi erent

    copyoftheOBPLbeformedforeachsuchreader.

    Everyrequestisdealtwithinauniformway,since

  • 8/2/2019 10.1.1.72.4304_DeadLock

    167/320

    thedetectiontechniquedoesnotclassifyrequestsaccordingtotherelationshipbetweentheoriginoftheprocessandtheaddresseddataresource.Inall

    otherapproaches20..22thealgorithmsdealwitheachaccessrequestaccordingtosomeclassi

  • 8/2/2019 10.1.1.72.4304_DeadLock

    168/320

    cation.

    Combinedapproachtodeadlockhandling

    Howard24hypothesizesthatnoneofthethreebasicapproachesalone|detection,avoidance,orpreventionis

    appropriatefortheentirespectrumofresourceallocationproblemsencounteredinoperatingsystems.

    Instead,individualtechniquescanbetailoredtooptimallyhandlesubproblemsofresourceallocation

    andstilloperategloballytopreventdeadlocks.Thebasisfor

  • 8/2/2019 10.1.1.72.4304_DeadLock

    169/320

    amixedtechniqueliesinthestructureofoperatingsystems.Resourceorderinginahierarchicalstructureprovidestheframework.Insomeoperatingsystems

    thishierarchyisintheformofenvelopinglayersofcapability.Eachlayer

    modi

  • 8/2/2019 10.1.1.72.4304_DeadLock

    170/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    171/320

    mechanisms.Inthecaseofresourceordering,thisimpliesthatanouterprocesscannotholdanyresourcesrequiredbytheinnerprocessitcreates.

    Sucharestrictionautomaticallyenforcesa\naturalorderingofresources,sinceresourcesrequired

    byinner-levelprocesseswouldautomaticallyappearlaterintheordering.

    By

    wayofillustration,considerthefollowingexampleinvolvingatypical

  • 8/2/2019 10.1.1.72.4304_DeadLock

    172/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    173/320

    edasfollows24:

    (1)spaceintheswappingstore;(2)assignabledevicessuchastapedrives,andjobresourcessuchasaccess

    to

  • 8/2/2019 10.1.1.72.4304_DeadLock

    174/320

    les;(3)centralmemoryforuserjobs;and(4)internalresourcessuchasmemoryfortransientsystemoverlays,andaccesstochannelsandcont

    rollers.InHoward'sidealmixed-methodsolutiontoresourcemanagement,theresourcesareorganized

    intothefourorderedclassesabove,andadi erentschemeisusedfor

    eachclass.Thus,preallocationmaybeusedfortheswapping

  • 8/2/2019 10.1.1.72.4304_DeadLock

    175/320

    space,sincethemaximumstoragerequirementsareusuallyknown.Sinceajobcanalwaysbeswappedout,centralmemorycanbepreempted,sodeadlock

    preventionisfeasible.Forjobresources,muchinformationabouttheintendedrequirementscan

    beobtainedfromthejobcontrolcards,sodeadlockavoidancecanbeused.

    Inprinciple,deadlockdetectionisalsopossible,sinceresourceordering

  • 8/2/2019 10.1.1.72.4304_DeadLock

    176/320

    canbeused,butproblemsmayariseif

  • 8/2/2019 10.1.1.72.4304_DeadLock

    177/320

    lepreemptionisattemptedduringanupdate.Finally,forinternalsystemresources,preventionthroughresourceorderingispossible,sincerun-timechoicesbetweenpendingrequests

    areunnecessary.AsHowardconcludes,\Thepracticaladvantagesofthecombinedapproachin

    operatingsystemswilloutweighthetheoreticaldesirabilityofusingasinglemethodthroughout:"24

    Acomprehensivecombinedapproachtodeadlockhandlingin

  • 8/2/2019 10.1.1.72.4304_DeadLock

    178/320

    databasesystemsordistributeddatabaseshasnotbeendevisedsofar.However,theideahasbeenappliedforon-linedetectionindistributeddatabases,where

    theremaybemultipleoutstandingrequestsonadataresourcereleasedbya

    completingprocess.In

    18

  • 8/2/2019 10.1.1.72.4304_DeadLock

    179/320

    DURODESTROY1111UPDATE1110READ1100OPEN100

    0

    Figure9.Blockingmatrixfor

  • 8/2/2019 10.1.1.72.4304_DeadLock

    180/320

    leoperations.

    thecaseofadeadlock-freesystem,anunwiseresourceallocationdecisioncanpotentiallyleadtodeadlockasdepictedinExample

    B.But,asshown,atleastoneprocessexists(inthesetof

    waitingprocesses)towhichtheresourcecanbeallocatedthatmaintainsthesystem

    deadlock-free.Inotherwords,apotentialdeadlockisdetectedand

  • 8/2/2019 10.1.1.72.4304_DeadLock

    181/320

    avoidedaccordingly.Theapproachusesbothdetectionandavoidanceprinciples.Thus,inthecaseofmultipleprocesseswaitingforaccesstoareleaseddata

    resource,theresourceisallocatedtothe

  • 8/2/2019 10.1.1.72.4304_DeadLock

    182/320

    rstprocesswhichmaintainsthesystemdeadlock-freeaftertheallocation.Furtherimprovementmaybepossiblebyallocatingtheresourcetothe

  • 8/2/2019 10.1.1.72.4304_DeadLock

    183/320

    rstprocesswhichnotonlymaintainsthesystemdeadlock-freebutalsohasminimumwaiting-accessrequestsonotherdataresources.

    Somecurrentdeadlock-handling

    implementations

    Inmoderntimesharingcomputersystems,thepotentialfordeadlockduring

    accesstothe

  • 8/2/2019 10.1.1.72.4304_DeadLock

    184/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    185/320

    c

  • 8/2/2019 10.1.1.72.4304_DeadLock

    186/320

    leoperationisperformed,the

  • 8/2/2019 10.1.1.72.4304_DeadLock

    187/320

    les

    26

    arelockedinoneofthreeinclusivelevels(read,update,ordestroy).Inordertoensurethattherules

    ofconcurrentusagearenotviolatedbeforelocking,MTSmaintainsatableindicating,

    atanyinstant,

    allthe

  • 8/2/2019 10.1.1.72.4304_DeadLock

    188/320

    lescurrentlyopenand/orlocked,

    howtheyarelockedandbywhattask(process),

    whattasksarecurrentlywaitingtolocka

  • 8/2/2019 10.1.1.72.4304_DeadLock

    189/320

    leandwhytheyarewaiting.Fromthistable,onecandeterminewhetherornotaparticulartypeofopeningand/orlockingofa

  • 8/2/2019 10.1.1.72.4304_DeadLock

    190/320

    lecan

    26

    beallowed,accordingtothefollowingrulesofconcurrentusage.

    (1)Ifa

  • 8/2/2019 10.1.1.72.4304_DeadLock

    191/320

    leisnotlockedforupdatingordestroying,anynumberoftaskscanhaveshared(read)accesstothis

  • 8/2/2019 10.1.1.72.4304_DeadLock

    192/320

    le.(2)Ifa

  • 8/2/2019 10.1.1.72.4304_DeadLock

    193/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    194/320

    lelockedforupdating(writing,emptying,ortruncating).(3)Ifa

  • 8/2/2019 10.1.1.72.4304_DeadLock

    195/320

    leisnotbeingused,thenonlyonetaskcanhavethis

  • 8/2/2019 10.1.1.72.4304_DeadLock

    196/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    197/320

    lecannotbelockedasrequested,thetaskisqueuedtowaitforthe

  • 8/2/2019 10.1.1.72.4304_DeadLock

    198/320

    le,butwaitingcanleadtodeadlockduetomutualblockingoftasks.Asde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    199/320

    nedbythematrixinFigure9,aprocesswishingtoupdatea

  • 8/2/2019 10.1.1.72.4304_DeadLock

    200/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    201/320

    le.Similarly,openinga

  • 8/2/2019 10.1.1.72.4304_DeadLock

    202/320

    leisonlyblockedbyaprocessintheactofdestroyingthe

  • 8/2/2019 10.1.1.72.4304_DeadLock

    203/320

    le.

    MTSmaintainstheinformationabout

  • 8/2/2019 10.1.1.72.4304_DeadLock

    204/320

    leusageinanMMmatrix,B.EachelementBij=1ifandonlyifTASKihasa

  • 8/2/2019 10.1.1.72.4304_DeadLock

    205/320

    leopenorlockedinsuchawaythatitblocksTASKj.NotethatMisthenumberof

    19

  • 8/2/2019 10.1.1.72.4304_DeadLock

    206/320

    P1P2P3P4P10100001000011000P20

    0100001100001

    00P30001100001

    000010P4100

  • 8/2/2019 10.1.1.72.4304_DeadLock

    207/320

    0010000100001B.=B+BB+BBB+BBBB

    Figure10.ComputationoftransitiveclosureforexampleshowninFigure7.

    tasksblockingorbeingblockedbyanothertask.Usuallythisisfar

    fewerthanthenumberofactivetasksorthenumber

  • 8/2/2019 10.1.1.72.4304_DeadLock

    208/320

    ofopen

  • 8/2/2019 10.1.1.72.4304_DeadLock

    209/320

    les.ThedeadlocksituationisdeterminedfromthestatusofmatrixB ,thetransitiveclosure10ofB.InessenceB.isobtainedbyORing

    therowsofBwitheachother.Thusfora33

    matrix,B.=B+BB+BBB.Consequently,ifB.=1

    thenTASKiisinvolvedinadeadlock.Fortheexample

  • 8/2/2019 10.1.1.72.4304_DeadLock

    210/320

    ii

    showninFigure7,afterP1andP3havebeenmadetowait,theexistenceofdeadlockisprovided

    bythecomputationofB.fromB,asshowninFigure10.

    Datamanagementsystems,ontheotherhand,varyinthewaythey

    detectandresolveadeadlock.As

    27

  • 8/2/2019 10.1.1.72.4304_DeadLock

    211/320

    othershavepointedout,manyoftheearlysystemsimplementedtechniqueswhichwerequiterudimentary.InproductssuchasIDMS|IntegratedDatabaseManagementSystem|Total,and

    Model204,deadlockisnotpossiblebecauseofrestrictionsonprocesses.Inthese

    systems,sinceaprocesscanlockonlyonerecordatatime,heavy

    restrictionsareplacedonuserstoensurethatdeadlocksnever

  • 8/2/2019 10.1.1.72.4304_DeadLock

    212/320

    occur.27Consequently,theyareneithergeneralnorrealisticandexhibitlowlevelsofconcurrentdataresourceusage.InAdabas|AdaptableDataBaseSystem27|onthe

    otherhand,ifaprocessrequestsalockedrecord

  • 8/2/2019 10.1.1.72.4304_DeadLock

    213/320

    vetimes,therecordisunlockedandcontroltransferredtotherequester.Thusitispossibleforaprocesstolosecontrolofa

    recordafterithaslockedit,necessitatingareacquisitionbeforetheupdateis

    repeated.Thismethodleadstounnecessarypreemptionsandisalsosubjecttocyclic

    restart,asillustratedinFigure3.

    Advancedmodels

  • 8/2/2019 10.1.1.72.4304_DeadLock

    214/320

    fordeadlockanalysis

    Althoughthebasicmodelsforanalyzingthedeadlocksituationincomputersystemshavebeenreviewed,manyotheraspectshave

    notbeencovered.Inparticular,wehavenotmentionedprobabilisticorgame-playing

    modelswhichattempttoavoiddeadlockbyensuring,withhighlikelihood,thatevery

    stateinthesystemissecure.Abrieftreatmentof

  • 8/2/2019 10.1.1.72.4304_DeadLock

    215/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    216/320

    theresourcemanager,RM,iscompetingagainstindependentprocesses

    28

    demandingservice.Inthiscase,themanagermaybethoughtof

    aswinningifalltheprocessescompletesuccessfully;theoppositionwinsifit

    createsadeadlock.Devillers28informallyde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    217/320

    nesdeadlockavoidance:\Fromsomeaprioriinformationabouttheprocesses,theresources,theoperatingsystem,etc.,determinewhatsituationsmayberealizedwithout

    endangeringthesmoothrunningofthesystem.

    Healsopresentsa

    owchartmodelwhichinsomesensegeneralizesthemaximum-claims7andtask-step9methods.Unfortunately,

    withthismodelitisnoteasytode

  • 8/2/2019 10.1.1.72.4304_DeadLock

    218/320

    nethesafestates,notonlybecauseaprocess

    20

  • 8/2/2019 10.1.1.72.4304_DeadLock

    219/320

    mayhavemorethanonepossibleseriesofstepsthatitmaytraverse(futurehistory),butalsobecausetheremaynotexista

    simpleworstpossiblefuturehistoryforeachprocess.

    Toovercomethis

    problemDevillersproposesaglobalapproach,inwhichastateisde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    220/320

    nedsafeifandonlyifastrategyexistsfortheRMwhichensuresitssuccesswhateveroperationtheprocessesinthatstatechoose.

    Astatewillbelosingifanoperationexistsfortheprocessessuch

    thattheRMwilllosethegamewhateverstrategyitchooses.Thisapproach

    throwsnewlightonthedeadlockproblembyprovidinga

  • 8/2/2019 10.1.1.72.4304_DeadLock

    221/320

    waytoconstructthesetofunsafestates,andhenceprovidingabasisforasystematicstudyofthepropertiesofthesafestates.

    29

    Probabilisticmodel.Aprobabilisticapproachtothedeadlockproblem

    hasalsobeentried,andaninvestigationmadeofthelikelihoodofdeadlock

    incertainclassesofsystems.Anystatediagramusedto

  • 8/2/2019 10.1.1.72.4304_DeadLock

    222/320

    representprocess-resourceinteractionscanalsobeviewedasa

  • 8/2/2019 10.1.1.72.4304_DeadLock

    223/320

    nitestateautomaton.Aprobabilitymeasurecanbeattachedtoanoccurrenceofeachpossibletransition.Arandomresourceallocationmodelisassumed,and

    thesumoftheprobabilitiesassociatedwithtransitionsoutofagivenstate

    isrequiredtobeunity.Byaddingauxiliarystoragetotheautomaton,

  • 8/2/2019 10.1.1.72.4304_DeadLock

    224/320

    rst-come-

  • 8/2/2019 10.1.1.72.4304_DeadLock

    225/320

    rst-serve(FCFS)andlast-come-

  • 8/2/2019 10.1.1.72.4304_DeadLock

    226/320

    rst-serve(LCFS)schedulerscanbemodeledtoform,respectively,aprobabilisticqueueautomatonandaprobabilistic

    29

    push-downautomaton.Thelikelihood

    ofdeadlockismeasuredintermsoftheexpectedvalueof(1)the

    numberofsystemactionstodeadlockor(2)thenumberofresourceallocations

    todeadlock.

    Calculationsarecarriedoutforsystems

  • 8/2/2019 10.1.1.72.4304_DeadLock

    227/320

    containingsmallnumbersofprocessesandresources.ForasystemwithtworesourcesandtwoprocessesthemeantimetodeadlockunderFCFSor

    LCFSschedulingisshowntobeslightlylessthanthatunderrandomallocation.

    Thefactthatonewouldexpecttheprobabilityofdeadlocktodecreaseif

    thenumberofunitsoftheresourcesincreases(whilethe

  • 8/2/2019 10.1.1.72.4304_DeadLock

    228/320

    numberofprocessesremains

  • 8/2/2019 10.1.1.72.4304_DeadLock

    229/320

    xed)issubstantiated.Conversely,ina

  • 8/2/2019 10.1.1.72.4304_DeadLock

    230/320

    xed-resourcesystem,increasingthenumberofprocessesincreasestheprobabilityofdeadlocksincemoreprocessescompeteforthesamenumberofresources.However,it

    isnotintuitivelyclearwhathappenstothedeadlockprobabilityifthenumber

    ofprocessesandresourcesareuniformlyincreased.Forsmallsystemsithasbeen

    shownthattheprobabilityofdeadlockactually

    29

  • 8/2/2019 10.1.1.72.4304_DeadLock

    231/320

    increases.However,sincethemodelconsiderednomorethan

  • 8/2/2019 10.1.1.72.4304_DeadLock

    232/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    233/320

    toolittleisunderstoodabouttherelativeprobabilityofinterferenceanddeadlock.Fortransactionprocessingsystems,itisthoughtthatinterferenceisrareand

    thatelaborateavoidancealgorithmswouldnotbeeconomical.30

    Becauseof

    theincreasingcomplexityofdistributeddatabases,thedeadlocksituationmustbehandlede ciently.

    However,itisdi culttoestimatetheperformancee ectsof

  • 8/2/2019 10.1.1.72.4304_DeadLock

    234/320

    thesetechniques,ortheprobabilityofoccurrenceofdeadlocks,sincecommunicationtimeiscritical.Asdistributeddatabasesbecomemorewidelyavailable,experimentaldatacan

    begatheredtomeasureperformancesandprobabilities,permittingexplorationofthecommunicationaspects.

    Acombinedapproachtohandlingdeadlocksindatabasesystemsisprobably

    themostpracticalsolution,buttheremaybefurtherproblems

  • 8/2/2019 10.1.1.72.4304_DeadLock

    235/320

    inintegrateddatabasesystemswhichallowprocessesaccesstoclassi

  • 8/2/2019 10.1.1.72.4304_DeadLock

    236/320

    eddata.Additionallevelsoflockingmaybenecessary,whichattheveryleastwillincreasethelockingcomplexity.

    21

  • 8/2/2019 10.1.1.72.4304_DeadLock

    237/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    238/320

    networkofcomputers,resultinginthedatabasesbecomingmoreaccessibletolargernumbersofdiverseapplicationjobs,thedatabaseadministrator'sfunctionbecomesincreasinglycomplex.

    Theactionsoftheoperatingsystem(whichmanagesapplicationjobs)andthoseof

    theDBA(whomaintainsprocessintegrityandtheconsistencyofthedatabase)have

    tobecoordinated.BoththeDBAandtheoperatingsystem

  • 8/2/2019 10.1.1.72.4304_DeadLock

    239/320

    designermustthoroughlyunderstandrelationshipsamongconcurrencycontrols,processors,processes,deadlock-handlingandrecoverytechniques,communicationaspects,andprotocols.Thisareaofresponsibilitybetweenthe

    systemdesignerandtheDBAcallsfordeeperstudy,especiallyinanetwork

    environment.

    Acknowledgments

    Thisresearchwassupportedinpartby

    agrantfromtheNationalScienceandEngineeringCouncilof

  • 8/2/2019 10.1.1.72.4304_DeadLock

    240/320

    Canada.

    Thee ortsofallCMPUT516studentswhocarefullyreadandcommentedonearlierversionsofthisarticlearemuchappreciated,

    butspecialthanksaredueTerryCrocker,MurrayReid,andArnoldRiverafor

    theirconstructivecriticismsandinsights.

    References

    1.R.M.

    MetcalfeandD.R.Boggs,\Ethernet:DistributedPacketSwitchingfor

  • 8/2/2019 10.1.1.72.4304_DeadLock

    241/320

    LocalComputerNetworks,Comm.ACM,Vol19,No.7,July1976,pp.395{404.2.S.E.MadnickandJ.J.Donovan,OperatingSystems,McGraw-Hill,

    NewYork,1974,pp.255{261.3.K.P.Eswaran,J.N.Gray,R.

    A.Lorie,andI.L.Traiger,\TheNotionsofConsistencyandPredicateLocks

    inaDataBaseSystem,Comm.ACM,Vol.19,No.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    242/320

    11,Nov.1976,pp.624{633.Thesigni

  • 8/2/2019 10.1.1.72.4304_DeadLock

    243/320

    cantdi erencesbetweenlockingprotocolsinashareddatabasesystemandthoseinanoperatingsystemarebroughtout.Theconceptsoftransaction

    andconsistencyarede

  • 8/2/2019 10.1.1.72.4304_DeadLock

    244/320

    ned.Itisshownthatmaintainingconsistencyimpliesthatatransactioncannotrequestnewlocksuntilafterithasreleasedallexistinglocks.

    4.J.N.Gray,\NotesonDataBaseOperatingSystems,in\Operating

    Systems(AnAdvancedCourse)inLectureNotesinComputerScience60,R.Bayer

    etal.,eds.,1978,PP.393{481.Thispaperisaconglomeration

  • 8/2/2019 10.1.1.72.4304_DeadLock

    245/320

    ofresearchresultsfromIBMauthorsengagedinthedevelopmentoftherelationaldatabasemanagementsystem,SystemR.Thereisathoroughdiscussionon

    datamanagement,datacommunications,transactionscheduling,consistencyandconcurrencyaspects,lockmanagement,and

    recoveryaspects.Theapproachisintuitiveandtutorial.Thisisanexcellentsource

    forobtainingabird's-eyeviewofadatabase-orientedoperatingsystem.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    246/320

    5.J.W.Havender,\AvoidingDeadlockinMultitaskingSystems,IBMSystemsJ.,Vol.7,No.2,1968,pp.74{84.22

  • 8/2/2019 10.1.1.72.4304_DeadLock

    247/320

    Theapproachessuggestedeliminatethepossibilityofdeadlocks.Thestrategiesusedinclude(a)requestingallrequiredresourcesatonce;(b)preemptingand

    rerequestingresources,inthecaseofadenialofincrementalrequestforresources;

    and(c)resourceordering.

    6.P.BrinchHansen,OperatingSystemPrinciples,

    Prentice-Hall,EnglewoodCli s,N.J.,1973,pp.42{49,124{125.7.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    248/320

    A.N.Habermann,\PreventionofSystemDeadlocks,Comm.ACM,Vol.12,No.7,July1969,pp.373{377,385.Theapproachisapracticalmodel

    andisagoodexampleofavoidance.Itusesthe\maximumclaimsstrategy

    withregardtoinformationonfutureresourcerequirementsofeachprocess.Deadlockavoidance

    isachievedbytestingeachpossibleallocationandmakingonly

  • 8/2/2019 10.1.1.72.4304_DeadLock

    249/320

    thosewhichleadtosafestates.

    8.R.C.Holt,\SomeDeadlockPropertiesofComputerSystems,ComputingSurveys,Vol.4,No.3,

    Sept.1972,pp.179{196.Athoroughandcomprehensivemodelforsystemsofinteracting

    processesispresented.Variousaspectsofdeadlocksinreusable-,consumable-,andgeneral-resourcesystems

    aredeveloped.Goodexamplesdescribeeverynewconceptandseveral

  • 8/2/2019 10.1.1.72.4304_DeadLock

    250/320

    existingproblems.Thetechniqueofgraphreductionsisdevelopedandusedindesigninge cientalgorithmsfordeadlockdetectionandprevention.Thepaperisclear

    andisanextremelygoodsourceforteachingdeadlockaspectsinoperatingsystems.

    9.E.G.Co man,Jr.,M.J.Elphick,andA.Shoshani,

    \SystemDeadlocks,ComputingSurveys,Vol.3,No.2,June1971,

  • 8/2/2019 10.1.1.72.4304_DeadLock

    251/320

    pp.67{78.Representationofprocessinteractionsbyastategraphisproposed.Amoreelaboratestatedescriptionmechanismissuggestedforrepresentinginteractionsin

    thecaseofmorethanoneresourceofatype.Usingsucha

    description,ane cientdeadlockdetectionandrecoverytechniqueisdesigned.Therecoverytechnique

    facilitatestheinclusionofpreemptibleresourcetypesofvaryingpreemption

  • 8/2/2019 10.1.1.72.4304_DeadLock

    252/320

    costsinthenotionofdeadlock.Severaltheoreticalaspectsofdeadlockavoidancearepresentedinformally.

    10.N.Deo,GraphTheorywithApplications

    toEngineeringandComputerScience,Prentice-Hall,EnglewoodCli s,N.J.,1974.11.A.

    ShoshaniandA.J.Bernstein,\SynchronizationinaParallelAccessedDataBase,Comm.

    ACM,Vol.12,No.11,Nov.1969,pp.604{607.Theconcurrent

  • 8/2/2019 10.1.1.72.4304_DeadLock

    253/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    254/320

    ConcurrentProcesses,Proc.1973NCC,Vol.42,AFIPSPress,Montvale,N.J.,June1973,pp.271{275.TheLOCK-UNLOCKmechanismoftheCodasylapproachto

    datamanagement,whichenablesincrementalallocations,isdescribed.Anecessaryandsu cient

    conditionfortheexistenceofdeadlockintermsofthee ectofthe

    ALLOCATEfunctionisderived.Usingthisadeadlockdetectionscheme

  • 8/2/2019 10.1.1.72.4304_DeadLock

    255/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    256/320

    Thetechniqueisaveryshrewdmodi

  • 8/2/2019 10.1.1.72.4304_DeadLock

    257/320

    cationandcombinationof(a)trytopreclaimneededresources;(b)ifpreclaimingresourcesleadstoadeadlock,preemptresources;and(c)imposea

    presequencingmechanismforprocessesbytimestamping,toavoiddeadlockduetoinde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    258/320

    nitedelay.

    14.G.Schlageter,\AccessSynchronizationandDeadlockAnalysisinDatabaseSystems:AnImplementation-OrientedApproach,InformationSystems,Vol.1,No.2,

    1975,pp.97{102.One-levellockoutandtwo-levellockoutmechanismsforaccesssynchronizationare

    discussed.Givenaprocessgraph,deadlockdetectionschemesforbothlockoutmechanismsare

    tostartattheblockedprocessnodeandtestif

  • 8/2/2019 10.1.1.72.4304_DeadLock

    259/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    260/320

    developed.Necessaryandsu cientconditionsfortheexistenceofadeadlockandtheavoidanceofdeadlockarederived.Adeadlockavoidanceschemeinthe

    eventofaprocessentry/deletionandresourcerequest/releaseisdevised.

    16.

    CODASYLDataBaseTaskGroupReport,Conf.onDataSystemLanguages,ACM,New

    York,Apr.1971.17.T.A.MarslandandS.S.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    261/320

    Isloor,\DetectionofDeadlocksinDistributedDatabaseSystems,INFOR,Vol.18,No.1,Feb.1980,pp.1{20.Adiscussionofdeadlock-handlingtechniquesindistributed

    systemsisprovided.Atutorialapproachtotheon-linedetectionmethodistaken.

    Examplesfromrealworldapplicationsaredepictedtoshowtherealityofa

    processhavingmultipleoutstandingresourcerequests.Forthiscase,the

  • 8/2/2019 10.1.1.72.4304_DeadLock

    262/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    263/320

    rstapproachrequirestheallocationofallneededresourcesbeforeprocessinitiation.Theconceptofaprocesssetisintroducedandusedinthe

    secondapproachproposedfordeadlockprevention.

    19.F.J.Maryanski,\A

    DeadlockPreventionAlgorithmforDistributedDataBaseManagementSystems,TechnicalReportCS77-02,

    ComputerScienceDept.,KansasStateUniversity,Manhattan,Kan.,Feb.1977,

  • 8/2/2019 10.1.1.72.4304_DeadLock

    264/320

    24pp.Preventionalgorithmrequireseachprocesstocommunicateitsshareddataresourceslisttoallotherprocessesbeforeitcanproceed.Theshared

    dataresourceslistisdeterminedbyusingprocesspro

  • 8/2/2019 10.1.1.72.4304_DeadLock

    265/320

    le.Proofofcorrectnessofthealgorithmissketched.

    20.A.N.Chandra,W.G.Howe,andD.P.Karp,\CommunicationProtocol

    forDeadlockDetectioninComputerNetworks,IBMTechnicalDisclosureBulletin,Vol.16,No.

    10,Mar.1974,pp.3471{3481.Thetechniqueofdeadlockdetectionrequiresthemaintenance

    ofresourcetablesateachinstallation,containinginformationonprocesses

  • 8/2/2019 10.1.1.72.4304_DeadLock

    266/320

    (local/remote)havingaccesstoresources(local/remote).Schemesfortheexpansionofresourcetablesaregiveninthenetworkenvironment.

    21.S.A.

    MahmoudandJ.S.Riordon,\SoftwareControlledAccesstoDistributedDataBases,INFOR,

    Vol.15,No.1,Feb.1977,pp.22{36.24

  • 8/2/2019 10.1.1.72.4304_DeadLock

    267/320

    Twoapproaches{centralizedcontrolanddistributedcontrol{todeadlockdetectionaresuggested.Thecentralizedapproachdetectsdeadlocksbycreatinganoverallglobalpictureofthe

    networkstatus.Inthedistributed-controlapproacheachcomputersendsidenticalmessagestoevery

    otherone,andreceivesdi erentmessagesfromeachone,sothatadeadlock

    maybedetectedatanyparticularinstallation.

    22.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    268/320

    B.Goldman,\DeadlockDetectioninComputerNetworks,TechnicalReportMIT/LCS/TR-185,LaboratoryforComputerScience,MIT,Cambridge,Mass.,Sept.1977,180pp.Thescheme

    isbasedonthecreationandexpansionofwhatiscalledanordered

    blockedprocesslist.TechniquestoexpandOBPLsbetweeninstallationsareprovidedtodetect

    deadlocksinthenetworkenvironment.Formalproofofcorrectness

  • 8/2/2019 10.1.1.72.4304_DeadLock

    269/320

    oftheschemeisprovided.Failureoftwopublishedalgorithmsisdemonstrated.

    23.S.S.IsloorandT.A.Marsland,\AnE ective

    'On-LineDeadlockDetectionTechniqueforDistributedDataBaseManagementSystems,Proc.COMPSAC78,

    Chicago,Ill.,Nov.1978,pp.283-288.

    Theapplicabilityofdeadlock

    detectionprinciplestodistributeddatabasesisinvestigated.Theconcept

  • 8/2/2019 10.1.1.72.4304_DeadLock

    270/320

    ofon-linedetectionofdeadlocksindistributedsystemsisde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    271/320

    nedandintroduced,andane ectivealgorithmforon-linedetectionissuggested.Severalhighlightsoftheproposalinadistributedenvironmentareemphasized.Further

    researchintheareaisidenti

  • 8/2/2019 10.1.1.72.4304_DeadLock

    272/320

    ed.

    24.J.H.Howard,Jr.,\MixedSolutionsfortheDeadlockProblem,Comm.ACM,Vol.16,No.7,July1973,pp.427{430.A

    thoroughdiscussionontheinappropriatenessoftheapplicabilityofdetection,avoidance,orprevention

    principlesalonefortheentirespectrumofresourceallocationproblemsinoperatingsystems

    isprovided.Amixedsolutioncombiningthebasicprinciplesand

  • 8/2/2019 10.1.1.72.4304_DeadLock

    273/320

    allowingtheselectionoftheoptimaloneforeachclassofresourcesinasystemissuggested.Withintheframeworkofresourceordering,the

    methodcloselycorrespondstothehierarchicalstructureofoperatingsystems.

    25.

    D.W.BoettnerandM.T.Alexander,\TheMichiganTerminalSystem,Proc.IEEE,

    Vol.63,No.6,June1975,pp.912{918.26.G.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    274/320

    C.Pirkola,\AFileSystemforaGeneralPurposeTimesharingEnvironment,Proc.IEEE,Vol.63,No.6,June1975,pp.918{924.27.D.C.

    TsichritzisandF.H.Lochovsky,DataBaseManagementSystems,AcademicPress,NewYork,

    1977.28.R.Devillers,\GameInterpretationoftheDeadlockAvoidanceProblem,Comm.ACM,

    Vol.20,No.10,Oct.1977,pp.741{745.Thedeadlockavoidanceproblem

  • 8/2/2019 10.1.1.72.4304_DeadLock

    275/320

    isde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    276/320

    nedasdeterminingsafesituationswhichmayberealizedwithoutendangeringthesmoothrunningofthesystem,fromsomecausalinformationabouttheprocesses,

    resources,andoperatingsystem.Aglobalapproachtothedeadlockphenomenonistaken,

    andtheevolutionofthesystemisinterpretedasagamebetweenthe

    operatingsystemand\naturerepresentedbytheprocesses.Thenotion

  • 8/2/2019 10.1.1.72.4304_DeadLock

    277/320

    ofriskandsafetyarepreciselyde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    278/320

    ned,andcanbeusedtostudythepropertiesofthesafestates.

    29.C.A.Ellis,\ProbabilisticModelsofComputerDeadlock,

    ReportCU-CS-041-74,Dept.ofComputerScienceUniversityofColorado,Boulder,Colo.,Apr.1974,

    25pp.Theprobabilityofincreaseordecreaseindeadlocks,asthenumber

    ofprocessesandresourceswithinacomputersystemincreases,is

  • 8/2/2019 10.1.1.72.4304_DeadLock

    279/320

    investigated.Amodelapplicabletotheinvestigationofthisproblemis

    25

  • 8/2/2019 10.1.1.72.4304_DeadLock

    280/320

    presented.Basicallytheprocess-resourceinteractionsaretreatedaspotentialmembersofthesetofstringsacceptedbyaprobabilisticautomaton.Resultsofcalculations

    onactualcomputersystemmodelsarealsodescribed,indicatingthattheprobabilityof

    deadlockincreasesforthetypesofsystemsconsidered.

    30.R.Peebles

    andE.Manning,\SystemArchitectureforDistributedDataManagement,Computer,

  • 8/2/2019 10.1.1.72.4304_DeadLock

    281/320

    Vol.11,No.1,Jan.1978,pp.40{47.Bibliography

    Bayer,R.,\OntheIntegrityofDataBasesandResourceLocking,inLectureNotes

    inComputerScience39,Proc.5thInformatikSymp.,H.HasselmeirandW.G.

    Spruth,eds.,Germany,Sept.1975,pp.339{361.

    Bayer,R.,\Integrity,Concurrency,

    andRecoveryinDatabases,inLectureNotesinComputerScience

  • 8/2/2019 10.1.1.72.4304_DeadLock

    282/320

    44,Proc.ECIConf.,K.Samelson,ed.,F.R.Germany,1976,pp.79{106.

    Bernstein,P.A.,J.B.Rothnie,Jr.,N.Goodman,

    andC.A.Papadimitriou,"TheConcurrencyControlMechanismofSDD-1:ASystemfor

    DistributedDatabases(TheFullyRedundantCase),IEEETrans.SoftwareEngineering,Vol.SE-4,No.3,

    May1978,pp.154{168.

    Bjork,L.A.,\Recovery

  • 8/2/2019 10.1.1.72.4304_DeadLock

    283/320

    SemanticsforaDB/DCSystem,Proc.ACMNat'lConf.,1973,pp.142{146.

    Braude,E.J.,\AnAlgorithmfortheDetectionofSystem

    Deadlocks,IBMTechnicalReportTR00.791,IBMDataSystemsDivision,Poughkeepsie,N.Y.,1968.

    Co man,E.G.,Jr.,andP.J.Denning,OperatingSystemsTheory,

    Prentice-Hall,EnglewoodCli s,N.J.,1973pp.31{82.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    284/320

    Collier,W.W.,\SystemDeadlocks,IBMTechnicalReportTR-00.1756,IBMSystemsDevelopmentDivision,Poughkeepsie,N.Y.,1968.

    Collmeyer,A.J.,\Database

    ManagementinaMulti-AccessEnvironment,Computer,Vol.4,No.6,Nov.-Dec.1971,pp.

    36{46.

    Curtice,R.M.,\IntegrityinDataBaseSystems,Datamation,May

    1977,pp.64{68.

    Date,C.J.,\Integrity(Chapter

  • 8/2/2019 10.1.1.72.4304_DeadLock

    285/320

    20),AnIntroductiontoDatabaseSystems,Addison-Wesley,Reading,Mass.,1975,pp.301{316.

    Davies,C.T.,\RecoverySemanticsforaDB/DCSystem,Proc.

    ACMNat'lConf.,1973,pp.136{141.

    Deppe,M.E.,andJ.

    P.Fry,\DistributedDataBases:ASummaryofResearch,ComputerNetworks,Vol.1,

    No.2,Sept.1976,pp.130{138.

    Ellis,C.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    286/320

    A.,\OntheProbabilityofDeadlockinComputerSystems,4thSymp.OperatingSystemPrinciples,Oct.1973.

    Eswaran,K.P.,andD.D.

    Chamberlin,\FunctionalSpeci

  • 8/2/2019 10.1.1.72.4304_DeadLock

    287/320

    cationsofaSubsystemforDatabaseIntegrity,Proc.Int'lConf.VeryLargeDataBases,Framingham,Mass.,Sept.1975,pp.44{68.

    26

  • 8/2/2019 10.1.1.72.4304_DeadLock

    288/320

    Everest,G.C.,\ConcurrentUpdateControlandDatabaseIntegrity,inDatabaseManagement,J.W.KlimbieandK.L.Ko eman,eds.,North-Holland,Amsterdam,1974,

    pp.241{270.

    Florentin,J.J.,\ConsistencyAuditingofDatabases,ComputerJ.,Vol.

    17,No.1,1974,pp.52{58.

    Fontao,R.O.,\AConcurrent

    AlgorithmforAvoidingDeadlocksinMultiprocessMultipleResourceSystems,

  • 8/2/2019 10.1.1.72.4304_DeadLock

    289/320

    Proc.3rdSymp.OperatingSystemPrinciples,Oct.1971.

    Fossum,B.M.,\DataBaseIntegrityasProvidedforbyaParticularDataBase

    ManagementSystem,inDatabaseManagement,J.W.KlimbieandK.L.Ko eman,eds.,

    North-Holland,Amsterdam,1974,pp.271{288.

    Frailey,D.J.,\APracticalApproach

    toManagingResourcesandAvoidingDeadlocks,Comm.ACM,Vol.16,

  • 8/2/2019 10.1.1.72.4304_DeadLock

    290/320

    No.5,May1973,pp.323{329.

    Fry,J.P.,andE.H.Sibley,\EvolutionofData-BaseManagementSystems,ComputingSurveys,Vol.8,

    No.1,Mar.1976,pp.7{42.

    Gardarin,G.,andS.Spaccapietra,

    \IntegrityofDatabases:AGeneralLockoutAlgorithmwithDeadlockAvoidance,inModelingin

    DataBaseManagementSystems,G.M.Nijssen,ed.,North-Holland,Amsterdam,1976,

  • 8/2/2019 10.1.1.72.4304_DeadLock

    291/320

    pp.395{411.

    Gold,E.M.,\DeadlockPrediction:EasyandDi cultCases,SIAMJ.Computing,Vol7,No.3,Aug.1978,pp.320{336.

    Goldstein,B.C.,\OntheResolutionofDeadlocks,IBMTechnicalReport

    TR00.2176-1,Poughkeepsie,N.Y.,1973.

    Gouda,M.G.,\AHierarchicalControllerfor

    ConcurrentAccessingofDistributedDatabases,Proc.FourthWorkshopComputerArchitecture

  • 8/2/2019 10.1.1.72.4304_DeadLock

    292/320

    forNon-NumericProcessing,SyracuseUniversity,N.Y.,Aug.1978,pp.65{70.

    Gray,J.N.,\Locking,ConcurrentSystemsandParallelComputation,Conf.Record,

    J.B.Dennis,ed.,1969.

    Gray,J.N.,\Lockingina

    DecentralizedComputerSystem,IBMResearchReportRJ1346,IBMResearchLaboratory,SanJose,

    Calif.,Feb.1974.

    Gray,J.N.,R.A.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    293/320

    Lorie,andG.R.Putzolu,\GranularityofLocksinaSharedDataBase,Proc.Int'lConf.VeryLargeDataBases,Framingham,Mass.,Sept.1975,

    pp.428{451.

    Gray,J.N.,R.A.Lorie,G.R.Putzolu,

    andI.L.Traiger,\GranularityofLocksandDegreesofConsistencyina

    SharedDataBase,inModelinginDataBaseManagementSystems,

  • 8/2/2019 10.1.1.72.4304_DeadLock

    294/320

    G.M.Nijssen,ed.,North-Holland,Amsterdam,1976,pp.365{394.

    Habermann,A.N.,IntroductiontoOperatingSystemDesign,ScienceResearchAssociates,Chicago,Ill.,

    1976,pp.80-85,325{336.

    Hawley,D.A.,J.S.Knowles,and

    E.E.Tozer,\DatabaseConsistencyandtheCODASYLDBTGProposals,TheComputerJournal,

    Vol.18,No.3,1975,pp.206{212.

    27

  • 8/2/2019 10.1.1.72.4304_DeadLock

    295/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    296/320

    Hebalkar,P.G.,\Deadlock-FreeResourceSharinginAsynchronousSystems,PhDdissertation,ElectricalEngineeringDept.,MIT,Cambridge,Mass.,Sept.1970.

    Herschberg,I.

    S.,andJ.C.A.Boekhorst,\ConcurrentFileAccessUnderUnpredictability,InformationProcessing

    Letters,Vol6,No.6,Dec.1977,pp.203{208.

    Holt,R.

    C.,\OnDeadlockinComputerSystems,PhDdissertation,Dept.of

  • 8/2/2019 10.1.1.72.4304_DeadLock

    297/320

    ComputerScience,CornellUniversity,Ithaca,N.Y.,Jan.1971.

    Holt,R.C.,\CommentsonPreventionofSystemDeadlocks,Comm.ACM,Vol.14,

    No.1,Jan.1971,pp.36{38.

    Hsiao,D.K.,SystemsProgramming,

    ConceptsofOperatingandDataBaseSystems,Addison-Wesley,Reading,Mass.,1975,pp.

    166{171.

    Iazeolla,G.G.,\Deadlock-FreeSequencingforMultiple

  • 8/2/2019 10.1.1.72.4304_DeadLock

    298/320

    ResourcesAllocationinMultiprocessSystems:OptimizationPerspectives,ReportNo.1-02,UniversitadiRoma,IstitutodiAutomatica,Rome,Italy,1971.

    Kameda,T.,\A

    Polynomial-TimeTestfortheDeadlock-FreedomofComputerSystems,inLectureNotesinComputer

    Science44,TheoreticalComputerScience3rd,GIConf.,G.GoosandJ.Hartmanis,

    eds.,F.

    R.Germany,Mar.1977,pp.282{291.

  • 8/2/2019 10.1.1.72.4304_DeadLock

    299/320

    Lomet,D.B.,\SubsystemsofProcessesforthePreventionofInde

  • 8/2/2019 10.1.1.72.4304_DeadLock

    300/320

    niteDelaywithDeadlockAvoidance,IBMResearchReportRC6897,IBMThomasJ.WatsonResearchCenter,YorktownHeights,N.Y.,Dec.1977.

    Lomet,D.B.,\Multi-LevelLockingwithDeadlockAvoidance,IBMResearchReportRC7019,

    IBMThomas

    J.WatsonResearchCenter,YorktownHeights,N.Y.,Mar.

    1978.Macri,P.P.,\DeadlockDetectionandResolutionina

  • 8/2/2019 10.1.1.72.4304_DeadLock

    301/320

    CODASYLBasedDataManagementSystem,Proc.ACM-SIGMODInt'lConf.ManagementofData,Washington,D.C.,June1976,pp.45{49.

    Mahmoud,S.A.,\Resource

    AllocationandFileAccessControlinDistributedInformationNetworks,PhDthesis,ElectricalEngineering

    Dept.,CarletonUniversity,Ottawa,Canada,Jan.1975.

    Mahmoud,S.A.,and

    J.S.Riordon,\ProtocolConsiderationsforSoftwareControlledAccessMethods

  • 8/2/2019 10.1.1.72.4304_DeadLock

    302/320

  • 8/2/2019 10.1.1.72.4304_DeadLock

    303/320

    ofIllinois,Urbana,