Stallo (informatica): differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m →Voci correlate: fix wl |
→Gestione: Forse il framework RTIC non è l'esempio più chiaro |
||
Riga 20:
== Gestione ==
=== Ignorare i deadlock ===▼
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]]<ref name="distri_tanen">{{Cita libro|cognome=Tanenbaum|nome=Andrew S.|url=https://books.google.com/books?id=l6sDRvKvCQ0C&q=Tanenbaum+ostrich&pg=PA177|editore=Pearson Education|anno=1995|titolo=Distributed Operating Systems|edizione=1st|p=117|isbn=9788177581799|accesso=16 ottobre 2020|urlarchivio=https://web.archive.org/web/20210418011235/https://books.google.com/books?id=l6sDRvKvCQ0C&q=Tanenbaum+ostrich&pg=PA177|urlmorto=}}</ref> ignorando di fatto l'esistenza dei deadlock. Questo può essere fatto in modo sicuro se viene [[Verifica formale|provato formalmente]] che i deadlock non si verificheranno mai.
<!-- Il framework RTIC utilizza questo metodo.<ref>{{Cita web|url=https://rtic.rs/0.5/book/en/|titolo=Preface - Real-Time Interrupt-driven Concurrency|accesso=1º ottobre 2020|urlarchivio=https://web.archive.org/web/20200918143731/https://rtic.rs/0.5/book/en/|urlmorto=}}</ref> -->
=== Evitare i deadlock ===
È una soluzione possibile solo se il sistema è capace di mantenere delle informazioni sulle risorse disponibili e sulle risorse che ogni processo può potenzialmente richiedere.
Riga 43 ⟶ 46:
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.
▲=== Ignorare i deadlock ===
▲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]]<ref name="distri_tanen">{{Cita libro|cognome=Tanenbaum|nome=Andrew S.|url=https://books.google.com/books?id=l6sDRvKvCQ0C&q=Tanenbaum+ostrich&pg=PA177|editore=Pearson Education|anno=1995|titolo=Distributed Operating Systems|edizione=1st|p=117|isbn=9788177581799|accesso=16 ottobre 2020|urlarchivio=https://web.archive.org/web/20210418011235/https://books.google.com/books?id=l6sDRvKvCQ0C&q=Tanenbaum+ostrich&pg=PA177|urlmorto=}}</ref> ignorando di fatto l'esistenza dei deadlock. Questo può essere fatto in modo sicuro se viene [[Verifica formale|provato formalmente]] che i deadlock non si verificheranno mai. Il framework RTIC utilizza questo metodo.<ref>{{Cita web|url=https://rtic.rs/0.5/book/en/|titolo=Preface - Real-Time Interrupt-driven Concurrency|accesso=1º ottobre 2020|urlarchivio=https://web.archive.org/web/20200918143731/https://rtic.rs/0.5/book/en/|urlmorto=}}</ref>
== Stato sicuro ==
|