Wat is het verschil tussen een deadlock en een race rond voorwaarde in programmeertermen?
Antwoord 1, autoriteit 100%
Denk aan een raceconditie met behulp van het traditionele voorbeeld. Stel dat u en een vriend een ATM-kaart hebben voor dezelfde bankrekening. Stel nu dat er $ 100 op de rekening staat. Bedenk wat er gebeurt als je $ 10 probeert op te nemen en je vriend probeert op precies hetzelfde moment $ 50 op te nemen.
Denk na over wat er moet gebeuren. De geldautomaat moet uw invoer opnemen, lezen wat er momenteel op uw rekening staat en vervolgens het bedrag wijzigen. Merk op dat in programmeertermen een toewijzingsinstructie een proces is dat uit meerdere stappen bestaat.
Dus, label uw beide transacties T1 (u neemt $ 10 op) en T2 (uw vriend neemt $ 50 op). De getallen hieronder, aan de linkerkant, vertegenwoordigen tijdstappen.
T1 T2
---------------- ------------------------
1. Read Acct ($100)
2. Read Acct ($100)
3. Write New Amt ($90)
4. Write New Amt ($50)
5. End
6. End
Nadat beide transacties zijn voltooid, met behulp van deze tijdlijn, wat mogelijk is als u geen enkel soort vergrendelingsmechanisme gebruikt, heeft het account $50. Dit is $ 10 meer dan zou moeten (je transactie is voor altijd verloren, maar je hebt nog steeds het geld).
Dit is een zogenaamde raceconditie. Wat u wilt, is dat de transactie serializeerbaaris, dat wil zeggen, hoe u de individuele instructie-uitvoeringen ook tussenvoegt, het eindresultaat zal exact hetzelfde zijn als sommigeseriële schema’s (wat betekent dat u ze de een na de ander uitvoert zonder interleaving) van dezelfde transacties. De oplossing is opnieuw om vergrendeling te introduceren; een onjuiste vergrendeling kan echter leiden tot een deadlock.
Deadlock treedt op wanneer er een conflict is met een gedeelde bron. Het is een soort Catch-22.
T1 T2
------- --------
1. Lock(x)
2. Lock(y)
3. Write x=1
4. Write y=19
5. Lock(y)
6. Write y=x+1
7. Lock(x)
8. Write x=y+2
9. Unlock(x)
10. Unlock(x)
11. Unlock(y)
12. Unlock(y)
Je kunt zien dat er een deadlock optreedt op tijdstip 7 omdat T2 probeert een slot op xte krijgen, maar T1 houdt het slot al vast op xmaar wacht op een slot voor y, die T2 bezit.
Dit is erg. Je kunt dit diagram omzetten in een afhankelijkheidsgrafiek en je zult zien dat er een cyclus is. Het probleem hier is dat x en y bronnen zijn die samen kunnen worden gewijzigd.
Een manier om dit soort deadlock-problemen met meerdere lock-objecten (bronnen) te voorkomen, is door een volgorde in te voeren. Je ziet, in het vorige voorbeeld, T1 vergrendeld xen dan ymaar T2 vergrendeld yen dan x. Als beide transacties hier voldoen aan een bestelregel die zegt: “xwordt altijd vergrendeld voor y“, dan zal dit probleem niet optreden. (U kunt het vorige voorbeeld wijzigen met deze regel in gedachten en u ziet dat er geen impasse optreedt).
Dit zijn triviale voorbeelden en eigenlijk heb ik zojuist de voorbeelden gebruikt die je misschien al hebt gezien als je een soort van bachelorcursus hierover hebt gevolgd. In werkelijkheid kan het oplossen van impasseproblemen veel moeilijker zijn dan dit, omdat je de neiging hebt om meer dan een paar bronnen en een paar transacties te hebben.
Ik hoop dat dit een beetje helpt. Gebruik zoals altijd Wikipedia als startpunt voor CS-concepten:
http://en.wikipedia.org/wiki/Deadlock
http://en.wikipedia.org/wiki/Race_condition
Antwoord 2, autoriteit 27%
Een deadlock is wanneer twee (of meer) threads elkaar blokkeren. Meestal heeft dit iets te maken met threads die gedeelde bronnen proberen te verwerven. Bijvoorbeeld als threads T1 en T2 zowel resources A als B moeten verwerven om hun werk te kunnen doen. Als T1 resource A verwerft, dan verwerft T2 resource B, dan zou T1 kunnen wachten op resource B terwijl T2 wachtte op resource A. In dit geval zullen beide threads voor onbepaalde tijd wachten op de resource die in het bezit is van de andere thread. Er wordt gezegd dat deze threads vastgelopen zijn.
Race-omstandigheden treden op wanneer twee threads op een negatieve (buggy) manier met elkaar omgaan, afhankelijk van de exacte volgorde waarin hun verschillende instructies worden uitgevoerd. Als een thread bijvoorbeeld een globale variabele instelt, en een tweede thread die globale variabele leest en wijzigt, en de eerste thread de variabele leest, kan er een fout optreden in de eerste thread omdat de variabele onverwacht is gewijzigd.
Antwoord 3, autoriteit 16%
Deadlock:
- Dit gebeurt wanneer 2 of meerthreads op elkaar wachtenom de bron voor een oneindige hoeveelheid tijd vrij te geven.
- Hierin zijn de threads in de geblokkeerde staat en worden ze niet uitgevoerd.
Race/Race-conditie:
- Dit gebeurt wanneer 2 of meerthreads parallel lopenmaar uiteindelijk een resultaat geven dat verkeerd is en niet equivalent als alle bewerkingen worden in volgorde gedaan.
- Hier worden alle threads uitgevoerd en worden hun bewerkingen uitgevoerd.
Bij codering moeten we zowel de race- als de impasse vermijden.
Antwoord 4, autoriteit 7%
Ik neem aan dat je “race-omstandigheden” bedoelt en niet “race rond-omstandigheden” (ik heb die term gehoord…)
Kortom, een dead lock is een toestand waarbij thread A wacht op resource X terwijl een lock op resource Y wordt vastgehouden, en thread B wacht op resource Y terwijl hij een lock op resource X vasthoudt. Het threadblok wacht op elkaar om hun sloten te ontgrendelen.
De oplossing voor dit probleem is (meestal) ervoor te zorgen dat je alle bronnen in de dezelfde volgordein alle threads vastzet. Als u bijvoorbeeld resource X altijd vóórresource Y vergrendelt, kan mijn voorbeeld nooit leiden tot een deadlock.
Een raceconditie is iets waarbij je vertrouwt op een bepaalde reeks gebeurtenissen die in een bepaalde volgorde plaatsvinden, maar dat kan in de war raken als er tegelijkertijd een andere thread actief is. Als u bijvoorbeeld een nieuw knooppunt in een gekoppelde lijst wilt invoegen, moet u de kop van de lijst wijzigen, meestal als volgt:
newNode->next = listHead;
listHead = newNode;
Maar als twee threads dat tegelijkertijd doen, dan heb je misschien een situatie waarin ze zo lopen:
Thread A Thread B
newNode1->next = listHead
newNode2->next = listHead
listHead = newNode2
listHead = newNode1
Als dit zou gebeuren, gaat de wijziging van de lijst door Thread B verloren omdat Thread A deze zou hebben overschreven. Het kan nog erger zijn, afhankelijk van de exacte situatie, maar dat is de basis.
De oplossing voor dit probleem is meestal om ervoor te zorgen dat u de juiste vergrendelingsmechanismen opneemt (u kunt bijvoorbeeld een slot verwijderen wanneer u de gekoppelde lijst wilt wijzigen, zodat slechts één thread deze tegelijk aanpast).
Antwoord 5
Met rust naar de programmeertaal als u gedeelde bronnen niet vergrendelt en toegang hebt tot meerdere threads, dan wordt dit “Race-conditie” genoemd, 2e geval als u de bronnen hebt vergrendeld en de reeksen van toegang tot gedeelde bronnen zijn niet correct gedefinieerd, dan worden threads kan lang wachten op de middelen om te gebruiken, dan is het een geval van “deadlock”