Stallo (informatica)

Disambiguazione – "Deadlock" rimanda qui. Se stai cercando altri significati, vedi Deadlock (disambigua).

Questa voce o sezione sull'argomento programmazione non cita le fonti necessarie o quelle presenti sono insufficienti.

---

Puoi migliorare questa voce aggiungendo citazioni da fonti attendibili secondo le linee guida sull'uso delle fonti.

In informatica, lo stallo o deadlock^[1] indica una situazione in cui due o più processi o azioni si bloccano a vicenda, aspettando che uno esegua una certa azione (per esempio rilasciare il controllo su una risorsa come un file, una porta input/output ecc.) che serve all'altro e viceversa.

Un esempio è rappresentato da due persone che vogliono disegnare: hanno a disposizione solo una riga e una matita e hanno bisogno di entrambe. Potendo prendere un solo oggetto per volta, se uno prende la matita, l'altro prende la riga, e se entrambi aspettano che l'altro gli dia l'oggetto che ha in mano, i due generano uno stallo.

Questa situazione può esser vista come un paradosso e non può essere risolta, ma si può prevenire. Applicazioni che sono tipicamente soggette agli stalli sono le basi di dati, nel caso in cui ci siano richieste circolari di accesso esclusivo da parte di diverse transazioni sulle stesse risorse, oppure i sistemi operativi che gestiscono l'accesso contemporaneo a file e a dispositivi di I/O di diversi processi.

In un deadlock si verificano sempre queste condizioni, dette anche di Havender:

1. Mutua esclusione: almeno una delle risorse del sistema deve essere 'non condivisibile' (ossia usata da un processo alla volta oppure libera).
2. Accumulo incrementale: i processi che possiedono almeno una risorsa devono attendere prima di richiederne altre (già allocate ad altri processi).
3. Impossibilità di prelazione: solo il processo che detiene la risorsa può rilasciarla.
4. Attesa circolare: esiste un gruppo di processi ${\displaystyle \{{P_{0},P_{1},\dots ,P_{n}}\}}$ per cui ${\displaystyle P_{0}}$ è in attesa per una risorsa occupata da ${\displaystyle P_{1}}$, ${\displaystyle P_{1}}$ per una risorsa di ${\displaystyle P_{2}}$, ecc. ${\displaystyle P_{n}}$ per una risorsa di ${\displaystyle P_{0}}$.

Una situazione di deadlock può essere riconosciuta analizzando il grafo delle attese dei processi del sistema.

I deadlock si possono verificare solo se sono presenti contemporaneamente le quattro condizioni di cui sopra (che sono quindi necessarie). Le condizioni diventano anche sufficienti nel caso di una sola istanza per ciascun tipo di risorsa.

È una soluzione possibile solo se il sistema è capace di mantenere delle informazioni sulle risorse disponibili e sulle risorse che ogni processo può potenzialmente richiedere.

Si definisce stato sicuro di un sistema quando è possibile eseguire i processi in una sequenza tale per cui, allocando a ognuno di essi tutte le risorse che potenzialmente può richiedere, gli si permetta di terminare la propria esecuzione e quindi evitare il deadlock. Se il sistema si trova in uno stato sicuro il deadlock può essere evitato, ma uno stato non sicuro non implica necessariamente un deadlock.

Il sistema può dunque evitare del tutto gli stalli se, a ogni richiesta di una risorsa da parte di un processo, effettua una verifica dello stato in cui si troverebbe allocando la risorsa. Se lo stato è sicuro la risorsa può essere tranquillamente allocata. A tal fine si può utilizzare l'algoritmo del banchiere.

Tuttavia, per la maggior parte dei sistemi è impossibile conoscere in anticipo le risorse che richiederà un processo, per cui è spesso impossibile evitare del tutto i deadlock.

In questo caso si cerca di evitare i deadlock annullando una o più delle condizioni di cui sopra: essendo esse collettivamente sufficienti basta infatti invalidarne una.

Per esempio:

1. Annullando la condizione di mutua esclusione e permettendo l'accesso contemporaneo a una stessa risorsa da parte di diversi processi (es. file aperti in lettura). Può essere impossibile come nei casi di scrittura su file o accesso a una risorsa senza spooling.
2. Si può richiedere a un processo di richiedere tutte le risorse di cui dovrà disporre all'avvio oppure con la convenzione di rilasciare una risorsa prima di richiederne un'altra. Spesso questa soluzione non è praticabile o poco efficace. Tuttavia è utilizzata nei database che fanno uso di two-phase locking.
3. Permettere la prelazione, il che quindi permetterebbe a un processo di rilasciare la risorsa detenuta da un altro processo: ciò può lasciare l'applicazione vittima in uno stato incoerente, dato che finisce per perdere una risorsa che stava utilizzando.
4. L'attesa circolare si può risolvere permettendo a ogni processo di richiedere solo una risorsa alla volta oppure imponendo un ordinamento (o una gerarchia) sui processi e prevenire in tal modo la formazione di cicli nel grafo delle attese.

Quando non è possibile evitare o prevenire i deadlock si possono solo definire degli algoritmi per riconoscere e risolvere gli stati di deadlock.

Per quanto riguarda la risoluzione, si può procedere con la terminazione di tutti i processi in stallo o di un processo per volta fino alla risoluzione del deadlock, oppure con la prelazione sulla risorsa che causa il problema. Particolare cura deve essere riposta nella scelta della vittima della prelazione.

In presenza di un sistema distribuito (come per esempio un database risiedente su diversi server), riconoscere una situazione di potenziale deadlock si rende ancora più complessa. In genere la rivelazione del possibile stato insicuro può essere effettuata solo ricostruendo il grafo delle attese globale a partire da quelli locali o con particolari algoritmi (vedi la variante distribuita del two-phase locking).

Tuttavia, la possibilità che il grafo delle attese globale non rifletta sempre correttamente l'effettivo stato del sistema distribuito, può rivelare dei deadlock inesistenti (phantom deadlocks) che sono già stati risolti perché uno dei processi ha terminato la sua esecuzione nel frattempo o che non sono mai esistiti realmente.

L'approccio consiste nell'assumere che il deadlock non avverrà mai. Se l'intervallo di tempo tra i deadlock è sufficientemente grande e la perdita di dati tollerabile, si può applicare l'algoritmo dello struzzo^[2] ignorando di fatto l'esistenza dei deadlock. Questo può essere fatto in modo sicuro se viene provato formalmente che i deadlock non si verificheranno mai. Il framework RTIC utilizza questo metodo.^[3]

Si definisce "stato sicuro" uno stato in cui è possibile allocare tutte le risorse richieste da un processo senza che questo finisca in un deadlock.

Il fatto che il sistema si trovi in uno stato sicuro non implica che tutte le allocazioni avverranno con successo, ma solo che esiste almeno un modo per allocare tutte le risorse. Se il sistema si trova in uno stato sicuro il deadlock può essere evitato, ma uno stato non sicuro non implica necessariamente un deadlock.

Il sistema può dunque evitare del tutto gli stalli se, a ogni richiesta di una risorsa da parte di un processo, effettua una verifica dello stato in cui si troverebbe allocando la risorsa. Se lo stato è sicuro la risorsa può essere tranquillamente allocata. A tal fine si può utilizzare l'algoritmo del banchiere.

Tuttavia, per la maggior parte dei sistemi è impossibile conoscere in anticipo le risorse che richiederà un processo, per cui è spesso impossibile evitare del tutto i deadlock visto che non si può determinare in anticipo se un futuro stato sarà sicuro.

• Algoritmo del banchiere
• Grafo delle attese
• Multithreading
• Processo (informatica)
• Thread (informatica)
• Sincronizzazione
• Starvation

• deadlock, su sapere.it, De Agostini.
• (EN) deadlock, su Enciclopedia Britannica, Encyclopædia Britannica, Inc.
• (EN) Denis Howe, deadlock, in Free On-line Dictionary of Computing. Disponibile con licenza GFDL

Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica