Deadlock (uváznutí)

Příklady z praxe

1. 01

   Dva mutexy v opačném pořadí

   Dvě funkce zamykají stejné mutexy v opačném pořadí. Při nevhodném proložení běhu první vlákno drží lock_a a čeká na lock_b, zatímco druhé vlákno drží lock_b a čeká na lock_a. Program se může zastavit bez výjimky, protože obě vlákna jen čekají.

   import threading
   
   lock_a = threading.Lock()
   lock_b = threading.Lock()
   
   def worker_1():
       with lock_a:
           with lock_b:
               print("hotovo 1")
   
   def worker_2():
       with lock_b:
           with lock_a:
               print("hotovo 2")
   
   threading.Thread(target=worker_1).start()
   threading.Thread(target=worker_2).start()

2. 02

   Převod mezi dvěma účty

   Dvě databázové transakce upravují stejné účty, ale každá začne jiným řádkem. První transakce zamkne účet 1 a čeká na účet 2, druhá zamkne účet 2 a čeká na účet 1. Databáze cyklus rozpozná a jednu transakci obvykle zruší, aby druhá mohla pokračovat.

   -- Transakce A
   BEGIN;
   UPDATE accounts SET balance = balance - 100 WHERE id = 1;
   UPDATE accounts SET balance = balance + 100 WHERE id = 2;
   COMMIT;
   
   -- Transakce B běží současně
   BEGIN;
   UPDATE accounts SET balance = balance - 50 WHERE id = 2;
   UPDATE accounts SET balance = balance + 50 WHERE id = 1;
   COMMIT;

Časté omyly

MýtusDeadlock je jen pomalý dotaz nebo pomalé vlákno.

Ve skutečnostiDeadlock je cyklus čekání, ve kterém žádná strana nemůže pokračovat bez zásahu. Pomalá operace může skončit sama, deadlock typicky vyžaduje zrušení jedné části práce nebo změnu zamykání.

MýtusStačí dát zámkům delší timeout a deadlock zmizí.

Ve skutečnostiDelší timeout pouze oddálí selhání a může zhoršit latenci celé aplikace. Příčina deadlocku zůstává v pořadí zamykání, délce držení zámků nebo v návrhu transakcí.

Časté dotazy

Jak poznám deadlock v databázi?

Deadlock v databázi se obvykle projeví chybou transakce, zprávou o detekovaném uváznutí nebo zrušením jednoho dotazu serverem. Aplikační kód by měl takovou chybu zachytit, provést rollback a zopakovat celou transakci. Pouhé opakování posledního příkazu může porušit logiku operace, protože předchozí kroky transakce už byly vráceny.

Vyřeší deadlock nastavení timeoutu?

Timeout čekání na zámek zabrání tomu, aby požadavek visel donekonečna, ale timeout sám neodstraňuje kruhovou závislost mezi držiteli zámků. Deadlock může po timeoutu zmizet jen proto, že jedna strana práci vzdala. Správná oprava hledá pořadí zamykání, délku transakcí, rozsah zámků a místa, kde se zámek drží zbytečně dlouho.

Proč deadlock není totéž co race condition?

Deadlock a race condition jsou různé chyby souběhu. Deadlock znamená, že účastníci čekají navzájem a výpočet nepokračuje. Race condition znamená, že výsledek závisí na přesném načasování operací, takže program někdy vrátí špatná data nebo poruší invariantu. Zámky mohou race condition opravit, ale špatně navržené zámky mohou zavést deadlock.

Jak se deadlockům předchází v praxi?

Deadlock lze často omezit pevným pořadím zamykání prostředků, krátkými kritickými sekcemi a návrhem, který nedrží zámek při síťovém volání nebo čekání na uživatele. V databázích pomáhá aktualizovat tabulky a řádky konzistentně, zkracovat transakce a opakovat transakci po detekovaném uváznutí. Úplné vyloučení bývá obtížné ve velkých distribuovaných systémech.

Zdroje

1. Deadlock(otevře se v novém okně)Wikipedia
2. Explicit Locking(otevře se v novém okně)PostgreSQL Global Development Group
3. SQL Server deadlocks guide(otevře se v novém okně)Microsoft Learn
4. Deadlock(otevře se v novém okně)Oracle

Související pojmy

• Race conditionRace condition je chyba souběhu, při níž správnost programu závisí na náhodném pořadí nebo načasování operací nad sdíleným stavem. Projeví se typicky ve vláknech, asynchronním kódu, databázových transakcích nebo distribuovaných systémech, kde dvě části programu čtou a mění stejná data bez dostatečné synchronizace.
• VláknoVlákno je samostatná posloupnost vykonávání instrukcí uvnitř procesu, kterou operační systém nebo běhové prostředí plánuje na procesor. Více vláken může sdílet paměť a otevřené zdroje stejného procesu, takže usnadňují souběžnou práci, ale vyžadují synchronizaci kvůli závodům, deadlockům a obtížně reprodukovatelným chybám.
• Databázová transakceDatabázová transakce je řízená skupina databázových operací, která se má provést jako jeden logický celek. Pokud se všechny kroky podaří, změny se potvrdí commitem; při chybě se vrátí rollbackem. Transakce chrání konzistenci dat hlavně při souběžných zápisech, výpadcích a více navazujících změnách.
• MutexMutex je synchronizační primitivum, které zaručuje, že do chráněné sekce kódu vstoupí v jednu chvíli nejvýše jedno vlákno. Vlákno zámek zamkne, provede práci nad sdílenými daty a zámek odemkne; ostatní vlákna mezitím čekají. Název vznikl zkrácením anglického mutual exclusion, tedy vzájemné vyloučení přístupu ke sdílenému prostředku.
• MultithreadingMultithreading je souběžné vykonávání více vláken uvnitř jednoho procesu, přičemž vlákna sdílejí stejný adresní prostor a otevřené soubory, ale mají vlastní zásobník a čítač instrukcí. Umožňuje využít víc jader procesoru najednou nebo pokračovat v práci, zatímco jiné vlákno čeká na disk či síť.
• Optimistické zamykáníOptimistické zamykání je způsob řízení souběžných zápisů, při kterém se záznam během čtení a úprav nezamyká a konflikt se odhalí až v okamžiku uložení: zápis proběhne jen tehdy, pokud se data mezitím nezměnila. Kontrola se obvykle dělá přes číslo verze nebo časové razítko a při neshodě aplikace operaci zopakuje.
• Paralelní zpracováníParalelní zpracování je způsob výpočtu, při kterém se úloha rozdělí na části běžící současně na více výpočetních jednotkách, typicky na jádrech procesoru, na GPU nebo na několika strojích v clusteru. Cílem je zkrátit dobu výpočtu, přičemž zrychlení omezuje ta část úlohy, kterou rozdělit nelze, a režie na komunikaci mezi částmi.
• ACIDACID je sada čtyř vlastností databázové transakce: atomicity, consistency, isolation a durability. Zaručuje, že skupina zápisů proběhne jako jeden celek, neporuší definovaná pravidla databáze, nebude se nebezpečně míchat s jinými transakcemi a po potvrzení přežije pád systému, například při převodu peněz.