View Full Version : [SO] Sottile differenza tra deadlock e starvation?
Matrixbob
10-12-2010, 17:30
Wikipedia non è il massimo della chiarezza, sopratutto perché collega male i 2 argomenti e non li contestualizza uno rispetto l'altro.
La starvation viene rappresentata tipicamente col problema dei 5 filosofi, mentre il deadlock con l'ingorgo stradale intorno a una piazza.
Quello che mi pare d'aver capito è che una starvation può diventare deadlock?
Quando ogni filosofo attende che si leberi l'altra bacchetta con cui mangiare, ma se capita che tutti attendono in circolo avviene il deadlock?
Il deadlock indipendentemente lo si ha quando ho una catena in cui ogni processo interessato attende che si liberi una risorsa detenuta da un'altro processo in attesa a sua volta, creando de facto in circolo vizioso infinito.
Chi mi sa chiarire maglio?
TNX!
Matrixbob
10-12-2010, 17:36
... poi attualmente pare che per mantenere presatazioni soddisfacenti i moderni SO non:
preveniscono evitano individuano e risolvono combianono quanto sopra visto
, scaricano sull'utente finale il problemone; devono essere i programmi a livello utente a preoccuparsene se è il caso.
Ma della starvation non mi sovviene nulla ... blackout totale!
mad_hhatter
10-12-2010, 17:43
Wikipedia non è il massimo della chiarezza, sopratutto perché collega male i 2 argomenti e non li contestualizza uno rispetto l'altro.
La starvation viene rappresentata tipicamente col problema dei 5 filosofi, mentre il deadlock con l'ingorgo stradale intorno a una piazza.
Quello che mi pare d'aver capito è che una starvation può diventare deadlock?
Quando ogni filosofo attende che si leberi l'altra bacchetta con cui mangiare, ma se capita che tutti attendono in circolo avviene il deadlock?
Il deadlock indipendentemente lo si ha quando ho una catena in cui ogni processo interessato attende che si liberi una risorsa detenuta da un'altro processo in attesa a sua volta, completando il ciclo.
Chi mi sa chiarire maglio?
TNX!
sono 2 concetti distinti.
si ha un deadlock quando un agente A si blocca in attesa che un agente B liberi una certa risorsa e B è a sua volta bloccato in attesa che A liberi un'altra risorsa. Gli agenti sono vicendevolmente bloccati e in attesa l'uno dell'altro senza possibilità di soluzione.
la starvation è la condizione per cui, pur non essendo in deadlock, un agente non riesce mai ad acquisire tutte le risorse di cui necessita. Supponi che 3 agenti A, B, C si contendano iterativamente una risorsa R senza particolari vincoli di precedenza: A acquisisce R, A rilascia R e torna a competere per essa, B acquisisce R, la rilascia e torna a competere per essa, A riacquisisce R, ecc... per puro caso C non riesce mai ad acquisire R, non perché sia bloccato, ma perché non essendoci vincoli di precedenza o altri criteri di arbitraggio, ogni agente ha, in ogni momento, la stessa probabilità degli altri di acquisire R. In questo caso si dice che C è soggetto a starvation.
Lo stesso si può dire se i criteri di arbitraggio per l'acquisizione di R fossero tali da sfavorire sempre un agente rispetto agli altri.
mad_hhatter
10-12-2010, 17:54
scusami, l'esempio di starvation è poco calzante perché basandosi solo sulla probabilità, prima o poi anche C deve poter entrare in possesso di R.
Riformuliamo l'esempio dicendo che ad A e B è stata accordata una priorità più alta di C sicché fin tanto che A e B tentano di acquisire R, C non sarà in grado di entrarne in possesso. Come vedi non possiamo parlare di deadlock: gli agenti non si bloccano a vicenda (c'è una sola risorsa in gioco).
Spero di essere stato più chiaro
Matrixbob
10-12-2010, 19:21
scusami, l'esempio di starvation è poco calzante perché basandosi solo sulla probabilità, prima o poi anche C deve poter entrare in possesso di R.
Riformuliamo l'esempio dicendo che ad A e B è stata accordata una priorità più alta di C sicché fin tanto che A e B tentano di acquisire R, C non sarà in grado di entrarne in possesso. Come vedi non possiamo parlare di deadlock: gli agenti non si bloccano a vicenda (c'è una sola risorsa in gioco).
Spero di essere stato più chiaro
Si + calzante.
Grazie CMQ a tutti.
nel caso di deadlock, un processo non ha più la possibilità di avere la risorsa che aspetta, perché c'è un attesa circolare delle risorse e nessun processo può progredire se una risorsa non viene liberata (la storia dell'attesa circolare la si può capire disegnando un grafo "delle attese" in cui i processi sono i nodi, e c'è un arco da un nodo a un altro se il primo è in attesa di una risorsa detenuta da un altro.. è chiaro che se c'è un ciclo in un grafo così fatto, vuol dire che tutti i processi sono bloccati in attesa di qualcosa che non arriverà mai)
la starvation è l'attesa indefinita, i processi non sono bloccati, solo che non è possibile definire a priori quando arriva il loro turno.. ad esempio se hai un mutex unfair, che sblocca i processi con una politica lifo, il primo che si è bloccato potrebbe non uscirne mai
in realtà trovare un esempio di starvation è difficile perché è difficile riprodurlo in un programma, è molto più facile ad esempio trovare la starvation negli algoritmi di scheduling (ad esempio shortest remaining time)
clockover
10-12-2010, 23:47
in realtà trovare un esempio di starvation è difficile perché è difficile riprodurlo in un programma, è molto più facile ad esempio trovare la starvation negli algoritmi di scheduling (ad esempio shortest remaining time)
qual'era quel fatto di quel processo che era stato in attesa chissà quanti anni e se ne sono accorti quando hanno spento il calcolatore :D :D appena lo trovo in rete posto il link :D :D più esempio di starvation di così
Matrixbob
11-12-2010, 08:50
qual'era quel fatto di quel processo che era stato in attesa chissà quanti anni e se ne sono accorti quando hanno spento il calcolatore :D :D appena lo trovo in rete posto il link :D :D più esempio di starvation di così
era al MIT che l'han scoperto ;)
ma quindi si verifica solo se ho alg con priorità?
starvation è "far morire di fame un processo" che non viene mai servito se non ricordo male.
E se ancora non ricordo male gli scheduler del tipo round robin definito "democratico" dal mio docente risolve tale problema dedicando ad esempio 20 ms di cpu per processo.
Il deadlock invece si realizza quando c'è contesa di una risorsa ed uno dei due processi contendenti non la libera mai: da qui uso di semafori e quant'altro.
clockover
11-12-2010, 09:07
starvation è "far morire di fame un processo" che non viene mai servito se non ricordo male.
E se ancora non ricordo male gli scheduler del tipo round robin definito "democratico" dal mio docente risolve tale problema dedicando ad esempio 20 ms di cpu per processo.
Ma così facendo però non c'è una differenziazione tra un processo ad alta priorità, ad esempio un processo interattivo, e uno con una bassa priorità! Sarebbero trattati tutti allo stesso modo e questo non è buono!
Ma così facendo però non c'è una differenziazione tra un processo ad alta priorità, ad esempio un processo interattivo, e uno con una bassa priorità! Sarebbero trattati tutti allo stesso modo e questo non è buono!
ciao,
in effetti poi ci è stato detto che ad esempio windows usa diversi tipi di scheduler a seconda del tipo di processo.
Comunque la spiegazione era per farci capire in cosa consiste la starvation :)
clockover
11-12-2010, 09:30
Si infatti è un ottimo esempio per introdurre algoritmi con fairness, per lasciare spazio poi a quelli più complessi e efficienti!
Matrixbob
11-12-2010, 09:44
Ma il TOP per la sincronizzazione allo stato dell'arte sono i "monitor"?
pabloski
11-12-2010, 11:14
il problema della starvation si risolve brillantemente con le code di priorità
in questo modo hai tante code, i processi nelle code a maggiore priorità sono "trattati meglio", ma tutte le code devono essere processate, non esiste che ci sia una coda che resta lì intoccata
Matrixbob
11-12-2010, 11:33
quindi stiamo parlando di problemi differenti o riguarda cose che si sovrappongono in qualche applicazione/contesto?
starvation --> scheduling di code senza priorità pesata dall'invecchiamento
deadlock --> richiesta di risorse per procedere
?
pabloski
11-12-2010, 12:22
quindi stiamo parlando di problemi differenti o riguarda cose che si sovrappongono in qualche applicazione/contesto?
starvation --> scheduling di code senza priorità pesata dall'invecchiamento
deadlock --> richiesta di risorse per procedere
?
direi che sono decisamente due cose diverse
la starvation è colpa del sistema operativo che dorme e non manda in esecuzione determinati processi
i deadlock sono in massima parte colpa delle applicazioni che si mettono a competere circolarmente per una o più risorse
se il primo problema il sistema operativo lo può risolvere facilmente, il secondo non è per nulla facile da risolvere
in genere il sistema operativo setta un timeout oltre il quale significa che il processo è andato in deadlock, ma poi decidere cosa fare è un altro paio di maniche
su un pc uccido il processo e buona notte, ma in una centrale nucleare le cose non sono così semplici
su un pc uccido il processo e buona notte, ma in una centrale nucleare le cose non sono così semplici
a me avevano raccontato che il razzo Arianne programmato dai francesi era precipitato per un problema di deadlock.
Difatti in molti settori tipo quello aereonautico, ma non solo, tali problemi guai se esistessero.
pabloski
11-12-2010, 13:41
a me avevano raccontato che il razzo Arianne programmato dai francesi era precipitato per un problema di deadlock.
Difatti in molti settori tipo quello aereonautico, ma non solo, tali problemi guai se esistessero.
l'hanno programmato maluccio allora :D
adesso capisco perchè chi tiene alla sicurezza usa qnx :sofico:
Matrixbob
11-12-2010, 14:09
Quindi quando programmo io programmatore ad esempio in Java devo essere io a gestire bene il multithreading usando correttamente i Synchronized Methods?
Della starvation invece me ne infischio?
Se Symbian ad esempio la gestisse malissimo (assunzione mia a cazzo) potrei trovarmi in quella situazione senza possibilità di operare, corretto?
a me avevano raccontato che il razzo Arianne programmato dai francesi era precipitato per un problema di deadlock.
Difatti in molti settori tipo quello aereonautico, ma non solo, tali problemi guai se esistessero.
Assolutamente no, è andata ancora peggio se vogliamo.
Hanno riciclato un modulo pensato per i 16bit in una architettura a 32bit, non tenendo conto del possibile overflow.
Le routine di controllo (se non erro ce n'erano più di una) sono andate in panico e hanno attivato la procedura di auto-distruzione, di fatto facendolo esplodere.
Ci sono svariati esempi di cattiva progettazione e programmazione, purtroppo anche in ambito medico.
In molti di questi ambiti andrebbe testata matematicamente la correttezza totale degli algoritmi in gioco, e credo che in alcuni casi lo facciano.
pabloski
11-12-2010, 15:55
Quindi quando programmo io programmatore ad esempio in Java devo essere io a gestire bene il multithreading usando correttamente i Synchronized Methods?
Della starvation invece me ne infischio?
Se Symbian ad esempio la gestisse malissimo (assunzione mia a cazzo) potrei trovarmi in quella situazione senza possibilità di operare, corretto?
nel caso di java e multithreading la starvation non ti tocca, perchè è un qualcosa su cui da programma non puoi avere controllo
se il sistema operativo si fissa che il tuo processo non ha diritto di essere eseguito c'è ben poca che tu possa fare
un sistema operativo che non sa risolvere il problema della starvation non è un sistema operativo ma un accrocchio senza senso :D
nel caso di java e multithreading la starvation non ti tocca, perchè è un qualcosa su cui da programma non puoi avere controllo
Anche no.
La starvation accade in un qualsiasi sistema dove degli agenti concorrenti a diverse priorità tentano di appropriarsi di una risorsa.
Quindi possono essere tranquillamente dei threads di uno stesso programma Java, o pure persone in coda dar macellaro.
Non è strettamente un problema di SO :D
Matrixbob
11-12-2010, 17:59
No ragazzi, qui stiamo cadendo nel mistico e insensato; cerchiamo di rimanere razionali e facciamo esempi reali e magari capitati, assodati o CMQ ben studiati!
CMQ anche a me la starvation mi pare roba da SO e che quindi dovrebbe riguardare Torvald e gli amici di Redmond, mentre la sincronia mi pare roba gestita da monitor e i buon vecchi semafori per accedere alla sezione critica di un pezzo di codice in comune.
[PS]
Tra l'altro mi sa che lo scheduling adesso sia roba da controller della CPU e manco + roba da SO.
pabloski
11-12-2010, 18:28
Anche no.
La starvation accade in un qualsiasi sistema dove degli agenti concorrenti a diverse priorità tentano di appropriarsi di una risorsa.
Quindi possono essere tranquillamente dei threads di uno stesso programma Java, o pure persone in coda dar macellaro.
Non è strettamente un problema di SO :D
no aspè, la starvation deriva dal fatto che un processo/thread sta lì fermo e viene lasciato a marcire
se parliamo di processi è un problema dell'OS, perchè il processo stesso non può farci nulla
se parliamo di thread dipende, nel senso che se il thread scheduling è responsabilità dell'OS allora il problema è suo, se invece è responsabilità della libreria che si occupa dei thread allora il problema è della libreria/programma
attualmente linux, windows e macos si occupano loro dello scheduling dei thread e quindi è loro responsabilità
nel caso di java dipende dalla jvm, se è una di quelle che mappano ogni thread java in un thread dell'OS allora la responsabilità ricade sull'OS
No ragazzi, qui stiamo cadendo nel mistico e insensato; cerchiamo di rimanere razionali e facciamo esempi reali e magari capitati, assodati o CMQ ben studiati!
CMQ anche a me la starvation mi pare roba da SO e che quindi dovrebbe riguardare Torvald e gli amici di Redmond, mentre la sincronia mi pare roba gestita da monitor e i buon vecchi semafori per accedere alla sezione critica di un pezzo di codice in comune.
[PS]
Tra l'altro mi sa che lo scheduling adesso sia roba da controller della CPU e manco + roba da SO.
si la starvation riferita ai processi è roba da sistema operativo, però per i thread c'è da dire che in alcuni casi/sistemi lo scheduling non è gestito dal sistema operativo
in ogni caso parlando specificamente di java comunque è un problema che non tocca il programmatore, perchè alla fine della fiera c'è una jvm bella e pronta e tu devi solo farci girare il tuo programma.....se la jvm ha un problema che genera starvation dei thread può farci ben poco
nel caso della sincronizzazione tra thread, invece, è tutto a tuo carico, sei l'unico responsabile dei casini che i thread combinano
alla fin fine il sistema operativo ti offre dei metodi per proteggere le risorse condivise ma che ne sa lui di quali/quante risorse userai, in che ordine e in quali momenti? e lo stesso vale per il deadlock che viene creato perchè tu programmatore non hai considerato che seguendo un certo percorso il programma poteva cadere nella trappola
Matrixbob
11-12-2010, 20:00
si la starvation riferita ai processi è roba da sistema operativo
Perchè che altra starvation esiste in informatica?
Quella di IO e RAM mi pare, ma io mi riferivo appunto al modello classico.
nel caso della sincronizzazione tra thread, invece, è tutto a tuo carico, sei l'unico responsabile dei casini che i thread combinano
Allora che la starvation se la gestisca il SO e che le sincronie le gestisca il programmatore siamo tutti d'accordo? Si? Ok.
alla fin fine il sistema operativo ti offre dei metodi per proteggere le risorse condivise ma che ne sa lui di quali/quante risorse userai, in che ordine e in quali momenti? e lo stesso vale per il deadlock che viene creato perchè tu programmatore non hai considerato che seguendo un certo percorso il programma poteva cadere nella trappola
Quindi per le sezioni critiche uso le funzioni disponibili a tale scopo.
Il deadlock se proprio non lo voglio gli applicherò qualche tecnica descritta nell'antologia informatica, seppur a scapito delle prestazioni velocistiche.
Tutti d'accordo sui 3 punti? Li accendiamo?
pabloski
11-12-2010, 20:32
Perchè che altra starvation esiste in informatica?
Quella di IO e RAM mi pare, ma io mi riferivo appunto al modello classico.
nel modello classico è riferita ai processi, però tieni presente che ovunque oggi si usano anche i thread e quelli pure possono essere soggetti a starvation
dipende dal sistema operativo però, perchè c'è chi schedula i thread tramite lo scheduler di sistema, chi si appoggia a librerie esterne ( a volte librerie utente )
ci sono poi alcune vm java che mappano più thread java in un thread dell'OS, per cui devono poi schedularli autonomamente
Allora che la starvation se la gestisca il SO e che le sincronie le gestisca il programmatore siamo tutti d'accordo? Si? Ok.
si
Quindi per le sezioni critiche uso le funzioni disponibili a tale scopo.
Il deadlock se proprio non lo voglio gli applicherò qualche tecnica descritta nell'antologia informatica, seppur a scapito delle prestazioni velocistiche.
certo, l'unica cosa è di analizzare il flusso del programma e capire se e dove qualche thread/processo può mettersi nei guai con i deadlock
nel modello client/server è impossibile che succeda, succede quando i processi sono paritetici per cui io aspetto che tu scendi dal taxi per salire, tu aspetti che io salga sul taxi per scendere e alla fine rimaniamo bloccati
clockover
11-12-2010, 23:04
La starvation riguarda anche la lettura dei dati dal disco comunque! Anche li però esistono vari algoritmi per risolvere il problema!
mad_hhatter
11-12-2010, 23:11
che la starvation sia roba solo da s.o. non è assolutamente vero!
è un problema di chi implementa la politica di accesso a una risorsa.
Il fatto che un processo venga selezionato e mandato in esecuzione dal s.o. non implica che questo stesso processo non possa essere soggetto a starvation dal punto di vista applicativo: ad esempio la logica applicativa potrebbe essere tale da non permettergli di acquisire le risorse richieste (che non sono soltanto il processore e altre risorse HW, ma soprattutto risorse logiche, proprie del dominio dell'applicazione in questione).
Starvation e deadlock non riguardano (solo) la possibilità di un processo di andare in esecuzione, ma più in generale, di portare a termine il proprio compito.
clockover
11-12-2010, 23:17
è un problema di chi implementa la politica di accesso a una risorsa.
più che giustissimo
pabloski
12-12-2010, 12:44
che la starvation sia roba solo da s.o. non è assolutamente vero!
è un problema di chi implementa la politica di accesso a una risorsa.
Il fatto che un processo venga selezionato e mandato in esecuzione dal s.o. non implica che questo stesso processo non possa essere soggetto a starvation dal punto di vista applicativo: ad esempio la logica applicativa potrebbe essere tale da non permettergli di acquisire le risorse richieste (che non sono soltanto il processore e altre risorse HW, ma soprattutto risorse logiche, proprie del dominio dell'applicazione in questione).
Starvation e deadlock non riguardano (solo) la possibilità di un processo di andare in esecuzione, ma più in generale, di portare a termine il proprio compito.
no no tu parli di un processo che va in blocco perchè magari entra in un ciclo infinito o appunto va in deadlock
la starvation è un problema che nasce dal multitasking e più specificamente dall'incapacità del sistema operativo di allocare le necessarie risorse che servono al processo
non vedo in che modo il processo possa essere responsabile di una cosa del genere
se non allochi una risorsa dall'interno del tuo programma allora non è starvation è un semplice bug
se non allochi una risorsa dall'interno del tuo programma allora non è starvation è un semplice bug
Ma che discorso è :asd:
Per avere starvation nel tuo programma, ti basta creare n thread che fanno polling su un mutex, e poi uno che tenta di acquisirlo quando arriva un evento esterno.
L'ultimo, il più "lento", avrà una probabilità bassissima che capiti l'evento in quei pochi ns in cui il mutex è sbloccato, e non riuscirà mai a completare il suo task.
Con un'architettura sbagliata tipo questa non ci sono jvm ne santi che ti salvano, mi dispiace :asd:
E come ho già detto la starvation è un problema generico, e non implica nemmeno che il task non verrà "mai" completato.
Per essere starvation è sufficiente che la risorsa sia indisponibile per un periodo di tempo "irragionevolmente" lungo, dove irragionevolmente dipende da quello che stai facendo, potrebbero anche solo essere pochi secondi in un SO realtime dove tutto va completato secondo programma.
Ad esempio, le prenotazioni di una discoteca: quelli con la prevendita entrano appena arrivano; gli altri sono in fila. Se vengono vendute troppe prevendite, quelli senza possono aspettare molto oltre l'inizio della serata, ed essere indotti a rinunciare al "task" di entrare.
A me sembra perfettamente simile al caso SO, ma sarà che astrarre è cosa rara :D
pabloski
12-12-2010, 14:47
Ma che discorso è :asd:
Per avere starvation nel tuo programma, ti basta creare n thread che fanno polling su un mutex, e poi uno che tenta di acquisirlo quando arriva un evento esterno.
questo è molto più simile ad un deadlock
in questo caso convieni che ci sono n thread che concorrono per ottenere l'accesso ad una risorsa? e che i thread sono tutt'altro che addormentati? nella starvation il problema è che non viene allocata la risorsa necessaria a far procedere il processo e quindi lo tieni lì fermo senza possibilità di farlo entrare in gioco
clockover
12-12-2010, 15:09
questo è molto più simile ad un deadlock
questa la vedo più starvation dato che comunque prima o poi tocca a lui, ma siccome non c'è nessuna policy che favorisce processi (o in questo caso thread) che sono in attesa di eventi esterni e che quindi sfruttano molto meno la CPU (e che molto probabilmente saranno di IO) allora aspetterà un tempo "irragionevolmente" lungo... qui entrano in gioco le differenze priorità
pabloski
12-12-2010, 15:51
questa la vedo più starvation dato che comunque prima o poi tocca a lui, ma siccome non c'è nessuna policy che favorisce processi (o in questo caso thread) che sono in attesa di eventi esterni e che quindi sfruttano molto meno la CPU (e che molto probabilmente saranno di IO) allora aspetterà un tempo "irragionevolmente" lungo... qui entrano in gioco le differenze priorità
no perchè se ogni thread è in grado di fare polling vuol dire che comunque verrà eseguito
la starvation si verifica quando un thread o processo non viene mai messo in esecuzione
Si ma che ci frega che verrà eseguito, se non porta avanti il suo task ma si limita a fare polling?
La starvation come la intendi tu non esiste, la probabilità che qualcosa non venga "mai" messo in esecuzione a causa delle race conditions è zero a parte che in casi veramente unici.
Mi sembra che ti sei affezionato troppo a quella definizione da manuale di SO.
In particolare il deadlock è una "starvation reciproca", dove ogni agente aspetta un'altro, e nessun task nel sistema viene portato avanti.
pabloski
12-12-2010, 16:19
Si ma che ci frega che verrà eseguito, se non porta avanti il suo task ma si limita a fare polling?
dal punto di vista pratico è un problema in ogni caso ma non è quello della starvation
Matrixbob voleva semplicemente sapere di quali problemi lui come programmatore si deve occupare e di quali problemi invece sono a carico del sistema operativo, virtual machine o che altro
la starvation è a carico loro, il deadlock è a carico del programmatore
La starvation come la intendi tu non esiste, la probabilità che qualcosa non venga "mai" messo in esecuzione a causa delle race conditions è zero a parte che in casi veramente unici.
ma come non esiste? se la definizione di starvation è proprio quella di un processo che non viene mai eseguito perchè scavalcato da processi a maggiore priorità
un utente ha pure portato l'esempio del programma che per un anno rimase in starvation senza mai avere nemmeno un ciclo di cpu con cui poter eseguire istruzioni :D
Mi sembra che ti sei affezionato troppo a quella definizione da manuale di SO.
beh se cominciamo ad inventarci termini nostri allora finisce che non ci capiamo più
In particolare il deadlock è una "starvation reciproca", dove ogni agente aspetta un'altro, e nessun task nel sistema viene portato avanti.
il deadlock è il deadlock e si chiama così proprio per distinguerlo dalla starvation
l'esempio che hai portato tu è un esempio al limite tra starvation e deadlock e infatti è definito livelock
ma il punto principale di tutto questo ambaradan è che Matrix può star sicuro che la starvation non è un problema suo mentre i deadlock si
Mah mi sembra decisamente un problema di definizione, veditelo come ti pare :D
Io fresco fresco della lezione di SO ricordo che è così, altro non ti posso dire.
clockover
12-12-2010, 17:45
ma come non esiste? se la definizione di starvation è proprio quella di un processo che non viene mai eseguito perchè scavalcato da processi a maggiore priorità
Secondo me è questo mai che è sbagliato... dal quel che mi riguarda io mi ricordo che la starvation avviene per un problema di policy sulle priorità e questo degrada in genere le prestazioni ma in sistemi time-sharing come quelli di oggi non interrompono l'esecuzione di un qualsiasi cosa (anche se qualcosa potrebbe risentirne se quel thread o processo che soffre di starvation è fondamentale)! Invece il deadlock è molto peggio! Se non sono specificati algoritmi per la prevenzione o la risoluzione non se ne esce proprio e non si va avanti! Possono poi esistere casi limite in cui un processo (o thread) soffra di starvation a tal punto da non andare avanti perchè sempre scavalcato! Ma non c'entra proprio nulla con il deadlock!
Io comunque nel mio piccolo cerco sempre di stare attento ad eventuali deadlock che possono verificarsi!
pabloski
12-12-2010, 18:15
Secondo me è questo mai che è sbagliato... dal quel che mi riguarda io mi ricordo che la starvation avviene per un problema di policy sulle priorità e questo degrada in genere le prestazioni ma in sistemi time-sharing come quelli di oggi non interrompono l'esecuzione di un qualsiasi cosa (anche se qualcosa potrebbe risentirne se quel thread o processo che soffre di starvation è fondamentale)! Invece il deadlock è molto peggio! Se non sono specificati algoritmi per la prevenzione o la risoluzione non se ne esce proprio e non si va avanti! Possono poi esistere casi limite in cui un processo (o thread) soffra di starvation a tal punto da non andare avanti perchè sempre scavalcato! Ma non c'entra proprio nulla con il deadlock!
Io comunque nel mio piccolo cerco sempre di stare attento ad eventuali deadlock che possono verificarsi!
in teoria la starvation implica che un processo non può completare la sua missione, quindi il mai è esatto....infatti se il processo venisse eseguito, anche se molto sporadicamente, non si parlerebbe di starvation ma di semplice degrado del sistema
il problema della starvation ovviamene non tocca chi fa i programmi perchè è a carico del sistema operativo e oggi qualsiasi sistema operativo sa come evitare questo problema
il deadlock è invece inevitabile perchè nasce proprio da un errore del programma, cosa che ovviamente il sistema operativo non può nè prevedere nè impedire, salvo poi uccidere i processi quando succede
sono d'accordo che la starvation non c'entra col deadlock e infatti non ho mai detto questo.....Matrix aveva chiesto "cos'è la starvation?" e "cos'è il deadlock"....quale dei due problemi è a carico mio? e quale a carico del sistema operativo/vm o che altro?
clockover
12-12-2010, 18:56
in teoria la starvation implica che un processo non può completare la sua missione, quindi il mai è esatto....infatti se il processo venisse eseguito, anche se molto sporadicamente, non si parlerebbe di starvation ma di semplice degrado del sistema
il problema della starvation ovviamene non tocca chi fa i programmi perchè è a carico del sistema operativo e oggi qualsiasi sistema operativo sa come evitare questo problema
il deadlock è invece inevitabile perchè nasce proprio da un errore del programma, cosa che ovviamente il sistema operativo non può nè prevedere nè impedire, salvo poi uccidere i processi quando succede
sono d'accordo che la starvation non c'entra col deadlock e infatti non ho mai detto questo.....Matrix aveva chiesto "cos'è la starvation?" e "cos'è il deadlock"....quale dei due problemi è a carico mio? e quale a carico del sistema operativo/vm o che altro?
Diciamo che per la definizione di starvation non riesco proprio a cambiare idea tanto facilmente... misà che mi dovrò dare uno sguardo al vecchio libro di SO, ma se hai ragione :mano:
Per quanto riguarda il deadlock ci sono degli accorgimenti che sui nostri programmi possiamo prendere per evitarli! Certo è ovvio che se sbagliamo noi i nostri codici il SO è innocente!
questo è molto più simile ad un deadlocksemmai livelock, perché il processo non è bloccato
mad_hhatter
13-12-2010, 08:57
la starvation si verifica quando un thread o processo non viene mai messo in esecuzione
no. la starvation si ha quando un thread non riesce (indefinitamente o per un tempo eccessivamente lungo per l'applicazione in esame) ad acquisire tutte le risorse necessarie al completamento del suo task. La cpu è SOLO UNA di queste risorse
banryu79
13-12-2010, 09:12
Starvation and livelock (http://download.oracle.com/javase/tutorial/essential/concurrency/starvelive.html).
I problemi di starvation (e livelock) e le relative responsabilità non vengono "sollevate" dal programmatore (parlo relativamente alla jvm) che non se ne deve preoccupare: per renderesene conto basta andare sui Java Technology Forums e sfogliare qualche discussione nella sezione dedicata alla programmazione concorrente.
mad_hhatter
13-12-2010, 09:22
Starvation and livelock (http://download.oracle.com/javase/tutorial/essential/concurrency/starvelive.html).
I problemi di starvation (e livelock) e le relative responsabilità non vengono "sollevate" dal programmatore (parlo relativamente alla jvm) che non se ne deve preoccupare: per renderesene conto basta andare sui Java Technology Forums e sfogliare qualche discussione nella sezione dedicata alla programmazione concorrente.
dal link che hai postato non emerge nulla che sgravi il programmatore dal preoccuparsi dei problemi di starvation (quando esistono, ovviamente)
sottovento
13-12-2010, 09:24
a me avevano raccontato che il razzo Arianne programmato dai francesi era precipitato per un problema di deadlock.
Difatti in molti settori tipo quello aereonautico, ma non solo, tali problemi guai se esistessero.
No, non era un deadlock. Ti parlo con cognizione di causa: ero li' e ho partecipato allo sviluppo :D
sottovento
13-12-2010, 09:25
l'hanno programmato maluccio allora :D
adesso capisco perchè chi tiene alla sicurezza usa qnx :sofico:
Beh, facciamo errori come li fanno tutti.
Pero' non capisco l'affermazione su qnx: si tratta di un OS run-to-completion, a maggior ragione avresti problemi di starvation in caso di errori....
sottovento
13-12-2010, 09:27
Assolutamente no, è andata ancora peggio se vogliamo.
Hanno riciclato un modulo pensato per i 16bit in una architettura a 32bit, non tenendo conto del possibile overflow.
Le routine di controllo (se non erro ce n'erano più di una) sono andate in panico e hanno attivato la procedura di auto-distruzione, di fatto facendolo esplodere.
Ci sono svariati esempi di cattiva progettazione e programmazione, purtroppo anche in ambito medico.
In molti di questi ambiti andrebbe testata matematicamente la correttezza totale degli algoritmi in gioco, e credo che in alcuni casi lo facciano.
Non e' andata nemmeno cosi'. Ad ogni modo i sistemi sul vettore erano a 16 bit, programmati in assembler e con parti in ada
banryu79
13-12-2010, 09:52
dal link che hai postato non emerge nulla che sgravi il programmatore dal preoccuparsi dei problemi di starvation (quando esistono, ovviamente)
Sì, è quello che infatti sostengo (oddio, sostengo... diciamo che è quello che ho capito io :D).
mad_hhatter
13-12-2010, 10:13
Sì, è quello che infatti sostengo (oddio, sostengo... diciamo che è quello che ho capito io :D).
dal tuo post precedente sembrava il contrario, sorry
banryu79
13-12-2010, 10:24
dal tuo post precedente sembrava il contrario, sorry In effetti la frase che ho scritto è interpretabile anche come hai fatto tu... mi sono espresso da cagnacci, chiedo venia :D
Volevo dire che il programmatore si deve preoccupare anche della starvation, non solo dei deadlock, la presenza di un intermediario tra lui e le chiamate al sistema operativo (jvm) non lo mettono al riparo/non lo giustificano da alcunchè. E' un problema di politiche di condivisione e accesso alle risorse da parte di più threads, come avete detto.
E alcune discussioni nel forum indicato presentano degli interessanti casi presi dal "mondo reale" di problematiche attinenti.
Matrixbob
14-12-2010, 21:31
Sul deadlock mi pare non ci siano discordie, allora in questi giorni ho scritto a Tanenbaum che mi ha spiegato che ho starvation a 2 livelli:
a livello SO e ci pensa lui utilizzando scheduling con piorità e invecchiamento, tipo l'algoritmo del fornaio, ma anche dei migliori;
a livello applicazione quando N processi vogliono entrare in sezione critica e in quel caso se il linguaggio ha dei costrutti standard potenti come monitor si usano quelli, altrimenti s'importa una qualche libreria non ufficiale di qualcuno o altrimenti s'implementa a manina la business logic come ad esempio "array dei processi" + "variabile turno" condivise, insomma i semplici semafori non bastan più.
Buonafortuna a noi.
Matrixbob
17-12-2010, 09:00
UP, allafine siam rimasti tutti d'accordo in questo modo?
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.