impasse - Deadlock
Bij gelijktijdig computergebruik is een deadlock een toestand waarin elk lid van een groep wacht tot een ander lid, inclusief zichzelf, actie onderneemt, zoals het verzenden van een bericht of het vrijgeven van een slot . Deadlocks zijn een veelvoorkomend probleem in multiprocessing- systemen, parallel computing en gedistribueerde systemen , waar software- en hardwarevergrendelingen worden gebruikt om gedeelde bronnen te arbitreren en processynchronisatie te implementeren .
Een besturingssysteem , een deadlock wanneer een proces of thread voert een wachtende toestand omdat een aangevraagde systeembron wordt vastgehouden door een ander wachtende taak, die op zijn beurt wacht op een bron die door een andere wachtende taak. Als een proces zijn status niet voor onbepaalde tijd kan wijzigen omdat de door het proces gevraagde resources worden gebruikt door een ander wachtend proces, dan zou het systeem in een impasse zitten.
In een communicatiesysteem treden impasses voornamelijk op als gevolg van verloren of corrupte signalen in plaats van conflict over hulpbronnen.
- Er wordt één proces doorlopen.
- Het latere proces moet wachten.
- Een deadlock treedt op wanneer het eerste proces de eerste resource vergrendelt op hetzelfde moment dat het tweede proces de tweede resource vergrendelt.
- De impasse kan worden opgelost door het eerste proces te annuleren en opnieuw te starten.
Noodzakelijke voorwaarden
Er kan zich een impasse op een resource voordoen als en alleen als alle volgende omstandigheden tegelijkertijd in een systeem voorkomen:
- Wederzijdse uitsluiting : er moeten ten minste twee bronnen in een niet-deelbare modus worden bewaard. Anders zouden de processen niet worden verhinderd om de bron te gebruiken wanneer dat nodig is. Slechts één proces kan de resource op een bepaald moment gebruiken.
- Hold and wait of resource vasthouden: een proces houdt momenteel ten minste één resource vast en vraagt om aanvullende resources die door andere processen worden vastgehouden.
- Geen voorkoop : een grondstof kan alleen vrijwillig worden vrijgegeven door het proces dat het bezit.
- Circulair wachten: elk proces moet wachten op een resource die wordt vastgehouden door een ander proces, dat op zijn beurt wacht tot het eerste proces de resource vrijgeeft. Over het algemeen is er een reeks wachtprocessen, P = { P 1 , P 2 , …, P N }, zodanig dat P 1 wacht op een hulpmiddel dat wordt vastgehouden door P 2 , P 2 wacht op een hulpmiddel dat wordt vastgehouden door P 3 etc. tot P N wacht op een bron bezit van P 1 .
Deze vier voorwaarden staan bekend als de Coffman-voorwaarden uit hun eerste beschrijving in een artikel uit 1971 van Edward G. Coffman, Jr.
Hoewel deze voorwaarden voldoende zijn om een impasse te veroorzaken op resourcesystemen met één instantie, duiden ze alleen op de mogelijkheid van een deadlock op systemen met meerdere instanties van resources.
Deadlock-afhandeling
De meeste huidige besturingssystemen kunnen deadlocks niet voorkomen. Wanneer een impasse optreedt, reageren verschillende besturingssystemen hierop op verschillende niet-standaard manieren. De meeste benaderingen werken door te voorkomen dat een van de vier Coffman-condities optreedt, vooral de vierde. De belangrijkste benaderingen zijn als volgt.
Impasse negeren
Bij deze benadering wordt aangenomen dat er nooit een deadlock zal optreden. Dit is ook een toepassing van het Ostrich-algoritme . Deze aanpak werd aanvankelijk gebruikt door MINIX en UNIX . Dit wordt gebruikt wanneer de tijdsintervallen tussen het optreden van deadlocks groot zijn en het gegevensverlies dat elke keer wordt opgelopen acceptabel is.
Het negeren van impasses kan veilig worden gedaan als formeel is bewezen dat impasses nooit voorkomen. Een voorbeeld is het RTIC-raamwerk.
Detectie
Onder de deadlock-detectie mogen deadlocks optreden. Vervolgens wordt de toestand van het systeem onderzocht om te detecteren dat er een impasse is opgetreden en vervolgens wordt deze gecorrigeerd. Er wordt een algoritme gebruikt dat de toewijzing van middelen en processtatussen volgt, het terugdraait en een of meer van de processen herstart om de gedetecteerde impasse te verwijderen. Het is gemakkelijk mogelijk om een reeds opgetreden impasse te detecteren, aangezien de resources die elk proces heeft vergrendeld en/of momenteel zijn aangevraagd, bekend zijn bij de resourceplanner van het besturingssysteem.
Nadat een impasse is gedetecteerd, kan deze worden gecorrigeerd met een van de volgende methoden:
- Procesbeëindiging: een of meer processen die betrokken zijn bij de impasse kunnen worden afgebroken. Men zou ervoor kunnen kiezen om alle concurrerende processen die bij de impasse betrokken zijn af te breken. Dit zorgt ervoor dat een impasse met zekerheid en snelheid wordt opgelost. Maar de kosten zijn hoog omdat gedeeltelijke berekeningen verloren gaan. Of men kan ervoor kiezen om één proces tegelijk af te breken totdat de impasse is opgelost. Deze aanpak heeft een hoge overhead omdat na elke afbreking een algoritme moet bepalen of het systeem nog steeds in een impasse zit. Bij het kiezen van een kandidaat voor beëindiging moet rekening worden gehouden met verschillende factoren, zoals prioriteit en leeftijd van het proces.
- Voorrang van middelen : middelen die aan verschillende processen zijn toegewezen, kunnen achtereenvolgens worden gepreëmpteerd en aan andere processen worden toegewezen totdat de impasse is doorbroken.
preventie
Deadlock-preventie werkt door te voorkomen dat een van de vier Coffman-condities optreedt.
- Het verwijderen van de voorwaarde voor wederzijdse uitsluiting betekent dat geen enkel proces exclusieve toegang heeft tot een bron. Dit blijkt onmogelijk voor bronnen die niet kunnen worden gespoold . Maar zelfs met in de wachtrij geplaatste bronnen kan de impasse nog steeds optreden. Algoritmen die wederzijdse uitsluiting vermijden, worden niet-blokkerende synchronisatie- algoritmen genoemd.
- De voorwaarden voor vasthouden en wachten of het vasthouden van middelen kunnen worden verwijderd door processen te verplichten alle benodigde middelen aan te vragen voordat ze worden opgestart (of voordat ze aan een bepaalde reeks bewerkingen beginnen). Deze voorkennis is vaak moeilijk te bevredigen en is in ieder geval een inefficiënte besteding van middelen. Een andere manier is om van processen te eisen dat ze alleen bronnen aanvragen als ze er geen hebben; Ten eerste moeten ze al hun huidige resources vrijgeven voordat ze alle resources die ze nodig hebben helemaal opnieuw aanvragen. Ook dit is vaak onpraktisch. Het is zo omdat middelen kunnen worden toegewezen en gedurende lange perioden ongebruikt blijven. Ook kan het zijn dat een proces dat een populaire resource nodig heeft, voor onbepaalde tijd moet wachten, omdat een dergelijke resource altijd aan een proces kan worden toegewezen, wat resulteert in uithongering van resources . (Deze algoritmen, zoals het serialiseren van tokens , staan bekend als de alles-of-niets-algoritmen .)
- De voorwaarde van geen voorkoop kan ook moeilijk of onmogelijk te vermijden zijn, omdat een proces gedurende een bepaalde tijd over een bron moet kunnen beschikken, of het verwerkingsresultaat kan inconsistent zijn of er kan thrashing optreden. Het onvermogen om voorrang af te dwingen kan echter interfereren met een prioriteitsalgoritme . Voorkoop van een "uitgesloten" bron impliceert over het algemeen een terugdraaiing en moet worden vermeden omdat dit zeer kostbaar is in overhead. Algoritmen die voorkoop mogelijk maken, zijn onder meer lock-free en wait-free algoritmen en optimistische gelijktijdigheidscontrole . Als een proces enkele bronnen bevat en vraagt om een of meer andere bronnen die er niet onmiddellijk aan kunnen worden toegewezen, kan de voorwaarde worden verwijderd door alle momenteel vastgehouden bronnen van dat proces vrij te geven.
- De laatste voorwaarde is de circulaire wachtvoorwaarde . Benaderingen die circulaire wachttijden vermijden, zijn onder meer het uitschakelen van onderbrekingen tijdens kritieke secties en het gebruik van een hiërarchie om een gedeeltelijke volgorde van resources te bepalen . Als er geen duidelijke hiërarchie bestaat, is zelfs het geheugenadres van bronnen gebruikt om de volgorde te bepalen en worden bronnen gevraagd in oplopende volgorde van de opsomming. Ook de oplossing van Dijkstra kan worden gebruikt.
Livelock
Een livelock is vergelijkbaar met een deadlock, behalve dat de toestanden van de processen die betrokken zijn bij de livelock voortdurend veranderen ten opzichte van elkaar, geen vooruitgang.
De term werd bedacht door Edward A. Ashcroft in een paper uit 1975 in verband met een onderzoek naar boekingssystemen van luchtvaartmaatschappijen. Livelock is een speciaal geval van uithongering van hulpbronnen ; de algemene definitie stelt alleen dat een bepaald proces niet vordert.
Livelock is een risico bij sommige algoritmen die deadlock detecteren en herstellen . Als meer dan één proces actie onderneemt, kan het algoritme voor deadlockdetectie herhaaldelijk worden geactiveerd. Dit kan worden voorkomen door ervoor te zorgen dat slechts één proces (willekeurig of met prioriteit) actie onderneemt.
Gedistribueerde impasse
Gedistribueerde impasses kunnen optreden in gedistribueerde systemen wanneer gedistribueerde transacties of gelijktijdigheidscontrole worden gebruikt.
Gedistribueerde deadlocks kunnen worden gedetecteerd door ofwel een globale wait-for-grafiek te construeren op basis van lokale wait-for-grafieken bij een deadlock-detector of door een gedistribueerd algoritme zoals edge-chasing .
Fantoomdeadlocks zijn impasses die ten onrechte worden gedetecteerd in een gedistribueerd systeem als gevolg van interne systeemvertragingen, maar die niet echt bestaan.
Als een proces bijvoorbeeld een resource R1 vrijgeeft en een verzoek om R2 doet , en het eerste bericht is verloren of vertraagd, kan een coördinator (detector van deadlocks) ten onrechte een deadlock sluiten (als het verzoek om R2 terwijl het hebben van R1 een impasse).
Zie ook
- Aporia
- Algoritme van de bankier
- Catch-22 (logica)
- Cirkelverwijzing
- Eetfilosofen probleem
- Bestandsvergrendeling
- Gridlock (in autoverkeer)
- Hangen (computeren)
- Impasse
- Oneindige lus
- lineariseerbaarheid
- Modelchecker kan worden gebruikt om formeel te verifiëren dat een systeem nooit in een impasse zal raken
- struisvogel algoritme
- Prioriteit inversie
- Race conditie
- Lezers-schrijver slot
- Slaap kapper probleem
- patstelling
- Synchronisatie (informatica)
- Routering met afslagbeperking
Referenties
Verder lezen
-
Kaveh, Nima; Emmerich, Wolfgang. "Deadlock-detectie in gedistribueerde objectsystemen" (PDF) . Londen: University College London. Cite journaal vereist
|journal=( hulp ) - Bensalem, Saddek; Fernandez, Jean-Claude; Havelund, Klaus; Mounier, Laurent (2006). Bevestiging van deadlock-potentialen gedetecteerd door runtime-analyse . Proceedings van de workshop van 2006 over parallelle en gedistribueerde systemen: testen en debuggen . ACM. blz. 41-50. CiteSeerX 10.1.1.431.3757 . doi : 10.1145/1147403.1147412 . ISBN 978-1595934147. S2CID 2544690 .
- Coffman, Edward G. Jr.; Elphick, Michael J.; Shoshani, Arie (1971). "Systeemimpasses" (PDF) . ACM Informatica-onderzoeken . 3 (2): 67-78. doi : 10.1145/356586.356588 . S2CID 15975305 .
- Mogul, Jeffrey C.; Ramakrishnan, KK (1997). "Het elimineren van ontvangen livelock in een interrupt-gestuurde kernel". ACM Transacties op computersystemen . 15 (3): 217-252. CiteSeerX 10.1.1.156.667 . doi : 10.1145/263326.263335 . ISSN 0734-2071 . S2CID 215749380 .
- Havender, James W. (1968). "Een impasse in multitasking-systemen vermijden" . IBM Systems Journal . 7 (2): 74. doi : 10.1147/sj.72.0074 .
- Holliday, Joanne L.; El Abbadi, Amr. "Gedistribueerde deadlock-detectie" . Encyclopedie van gedistribueerde computers . Gearchiveerd van het origineel op 2 november 2015 . Ontvangen 29 december 2004 .
- Knapp, Edgar (1987). "Deadlock-detectie in gedistribueerde databases". ACM Informatica-onderzoeken . 19 (4): 303-328. CiteSeerX 10.1.1.137.6874 . doi : 10.1145/45075.46163 . ISSN 0360-0300 . S2CID 2353246 .
- Ling, Yibei; Chen, Shigang; Chiang, Jason (2006). "Op Optimale Deadlock Detection Scheduling". IEEE-transacties op computers . 55 (9): 1178-1187. CiteSeerX 10.1.1.259.4311 . doi : 10.1109/tc.2006.151 . S2CID 7813284 .
Externe links
- " Geavanceerde synchronisatie in Java-threads " door Scott Oaks en Henry Wong
- Agenten voor deadlockdetectie
- DeadLock in de Portland Pattern Repository
- Etymologie van "deadlock"