Roberto Pulito

MIT, il defibrillatore che rianima il software

Gli studiosi del MIT lavorano ad un strumento che risveglia i processi in stallo, interrompendo il loop infinito

Roma - Ogni moderno sistema operativo possiede uno strumento che permette di monitorare i processi in esecuzione sulla macchina, ma quando un programma si blocca irreparabilmente e la sua finestra resta impressa sul monitor si può solo tentare di forzare la chiusura. Con buona pace dei lavori in corso.

Per questo motivo i ricercatori del Massachusetts Institute of Technology (MIT) stanno lavorando ad un innovativo sistema che prova a sbloccare il software in stallo, senza perdita di dati. Un vero e proprio defibrillatore da utilizzare con le applicazioni rimaste appese, che consentirà di salvare i dati e completare il lavoro prima di riavviare davvero.

Il freeze dei programmi è legato principalmente al loop infinito, all'esecuzione ripetuta di un singolo stralcio di codice. Per uscire da questa frustrante modalità, i ricercatori del MIT hanno messo a punto uno strumento chiamato Jolt che interrompe i cicli infiniti, spingendo il software sulla successiva riga di codice.
Il framework in questione è già stato sperimentato in diverse situazioni anche se per il momento funziona solamente con applicazioni "semplici". La prima versione di Jolt non è in grado di rilevare tutte le condizioni che possono portare al blocco di un software in esecuzione e non può controllare i cicli di loop dei programmi più avanzati senza appesantire il sistema.

Roberto Pulito
Notizie collegate
  • BusinessIl MIT e le buone azioni del Dr. BoseAmar Bose ha deciso di donare al prestigioso ateneo statunitense la maggioranza delle azioni dell'azienda da lui fondata. Saranno sfruttate in ambiti come la ricerca e l'insegnamento. L'universitÓ non avrÓ per˛ facoltÓ di voto
  • AttualitàMIT: niente (più) lezioni gratis su Internet?Al vaglio l'ipotesi di rimuovere la possibilitÓ di scaricare gratuitamente i podcast e gli appunti delle lezioni. Un paywall all'orizzonte da innalzare in tempo di crisi? - UPDATE
62 Commenti alla Notizia MIT, il defibrillatore che rianima il software
Ordina
  • while (!ack)
    {
    wait_for_ack();
    }
    signal_successful_communication_to_happy_user();
    non+autenticato
  • Il C fornisce l'istruzione "break" il cui scopo è proprio quello di uscire prematuramente da un ciclo con un salto all'istruzione successiva. Quindi:

    if (sto girando a vuoto)
       break;

    (Ovviamente, se il programmatore sa dove mettere le mani).

    Uno strumento che forza incondizionatamente l'esecuzione dell'istruzione successiva ad un ciclo potrebbe essere molto pericoloso; pensiamo al caso in cui proprio all'interno del ciclo stesso siano presenti istruzioni vitali per il corretto salvataggio dei dati.
    non+autenticato
  • - Scritto da: Alvaro Vitali
    > Il C fornisce l'istruzione "break" il cui scopo è
    > proprio quello di uscire prematuramente da un
    > ciclo con un salto all'istruzione successiva.
    > Quindi:
    >
    > if (sto girando a vuoto)
    >    break;
    >

    Se non sei in grado di giustificare analiticamente la condizione "sto girando a vuoto", questa me la stampo e la metto nel faldone delle
    "CAZZATE COLOSSALI TROVATE IN INTERNET"
    non+autenticato
  • - Scritto da: attonito
    >
    > Se non sei in grado di giustificare
    > analiticamente la condizione "sto girando a
    > vuoto", questa me la stampo e la metto nel
    > faldone delle
    > "CAZZATE COLOSSALI TROVATE IN INTERNET"

    Infatti ho scritto: "(Ovviamente, se il programmatore sa dove mettere le mani)" ...

    ... che significa: "se il programmatore ha il sospetto che un determinato ciclo possa andare in loop infinito, può inserire apposite istruzioni diagnostiche".

    In C è facilissimo tempestare un programma di istruzioni diagnostiche con la possibilità poi di rimuoverle automaticamente quando il programma è pronto; bastano, ad esempio, una serie di "#ifdef".
    non+autenticato
  • - Scritto da: Alvaro Vitali
    > - Scritto da: attonito
    > >
    > > Se non sei in grado di giustificare
    > > analiticamente la condizione "sto girando a
    > > vuoto", questa me la stampo e la metto nel
    > > faldone delle
    > > "CAZZATE COLOSSALI TROVATE IN INTERNET"
    >
    > Infatti ho scritto: "(Ovviamente, se il
    > programmatore sa dove mettere le mani)"
    > ...
    >
    > ... che significa: "se il programmatore ha il
    > sospetto che un determinato ciclo possa andare in
    > loop infinito, può inserire apposite istruzioni
    > diagnostiche".
    >

    che michia di unita' di misura e' "se ha il sospetto"?
    riprova.
    non+autenticato
  • - Scritto da: Alvaro Vitali
    > Il C fornisce l'istruzione "break" il cui scopo è
    > proprio quello di uscire prematuramente da un
    > ciclo con un salto all'istruzione successiva.
    > Quindi:
    >
    > if (sto girando a vuoto)
    >    break;
    >
    > (Ovviamente, se il programmatore sa dove mettere
    > le
    > mani).
    >

    Oppure puoi evitare di usare i cicli. È molto semplice:

    for (i=0; i<n; i++) do_something();

    diventa

    if (n==1)
       do_something();
    else if (n==2) {
       do_something(); do_something();
    } else if (n==3) {
       do_something(); do_something(); do_something();
    } eccetera...

    È anche molto più ottimizzato dal punto di vista della velocità di esecuzione.

    F
    non+autenticato
  • - Scritto da: Francesco
    > - Scritto da: Alvaro Vitali
    > > Il C fornisce l'istruzione "break" il cui
    > scopo
    > è
    > > proprio quello di uscire prematuramente da un
    > > ciclo con un salto all'istruzione successiva.
    > > Quindi:
    > >
    > > if (sto girando a vuoto)
    > >    break;
    > >
    > > (Ovviamente, se il programmatore sa dove
    > mettere
    > > le
    > > mani).
    > >
    >
    > Oppure puoi evitare di usare i cicli. È
    > molto
    > semplice:
    >
    > for (i=0; i<n; i++) do_something();
    >
    > diventa
    >
    > if (n==1)
    >    do_something();
    > else if (n==2) {
    >    do_something(); do_something();
    > } else if (n==3) {
    >    do_something(); do_something(); do_something();
    > } eccetera...
    >
    > È anche molto più ottimizzato dal punto di
    > vista della velocità di
    > esecuzione.
    >
    > F

    mi spiace ma gli "if" ammazzano il sistema molto piu dei "for".
    non+autenticato
  • - Scritto da: attonito
    > mi spiace ma gli "if" ammazzano il sistema molto
    > piu dei
    > "for".

    Uhm non ne sono sicuro. A livello di codice macchina duro e puro il numero di comparazioni e di jump è lo stesso (ogni for alla fine è un JNE) e con la serie di if ti risparmi l'aritmetica di incremento del contatore...

    Comunque la mia era solo una provocazione, ovviamenteSorride
    non+autenticato
  • - Scritto da: Francesco
    > - Scritto da: attonito
    > > mi spiace ma gli "if" ammazzano il sistema
    > molto
    > > piu dei
    > > "for".
    >
    > Uhm non ne sono sicuro. A livello di codice
    > macchina duro e puro il numero di comparazioni e
    > di jump è lo stesso (ogni for alla fine è un JNE)
    > e con la serie di if ti risparmi l'aritmetica di
    > incremento del
    > contatore...

    in C gli if ammazzano piu dei for. provaci.

    > Comunque la mia era solo una provocazione,
    > ovviamente
    >Sorride
    ah be allora....
    non+autenticato
  • La tecnica che si utilizza in questi casi consiste nell'uso massiccio di macro come #ifdef, #ifndef, etc.

    Ad esempio, in fase di test di un programma:

    #define TEST1

    #ifdef TEST1
       blocco_codice_1
    #else
       blocco_codice_2
    #endif

    Alla fine, quando si è sicuri che è tutto a posto, basta rimuovere la definizione di TEST1 per fare in modo che in fase di ricompilazione, il "blocco_codice_1" venga eliminato dall'eseguibile finale ...

    ... e naturalmente, per la Legge di Murphy, possiamo stare certi che il bug che determina il loop infinito si trovava invece nel "blocco_codice_2"!
    non+autenticato
  • - Scritto da: Alvaro Vitali
    > La tecnica che si utilizza in questi casi
    > consiste nell'uso massiccio di macro come #ifdef,
    > #ifndef,
    > etc.
    >
    > Ad esempio, in fase di test di un programma:
    >
    > #define TEST1
    >
    > #ifdef TEST1
    >    blocco_codice_1
    > #else
    >    blocco_codice_2
    > #endif
    >
    > Alla fine, quando si è sicuri che è tutto a
    > posto, basta rimuovere la definizione di TEST1
    > per fare in modo che in fase di ricompilazione,
    > il "blocco_codice_1" venga eliminato
    > dall'eseguibile finale
    > ...
    >
    > ... e naturalmente, per la Legge di Murphy,
    > possiamo stare certi che il bug che determina il
    > loop infinito si trovava invece nel
    > "blocco_codice_2"!

    e quindi non serve a un cippirimerlo.
    secondo me e' un buco nell'acqua, vedremo i tizi del MIT quale coniglio estrarranno dal cappello del mago....
    non+autenticato
  • Per l'efficienza a questo punto fai una ricerca binaria tra 1 e n che ha tempo di esecuzione logaritmico, e sei messo molto meglio che non una ricerca lineare come nell'esempio.
    Poi voglio vederti però...

    if n==100
    // k righe di codice prima volta
    // k righe di codice (le stesse) seconda volta
    ...
    // k righe di codice 100 volta

    Questo per ogni n ammissibile...
    Qualche problema:
    - 1 ti passa la voglia di scrivere tutto il codice, fai prima a scrivere un programma che ti scriva il codice (ma non dovevano pensarci i compilatori a questo tipo di ottimizzazioni?),
    - 2 non so se a occhio riesci a distinguere il caso 98 da quello 99
    - 3 il codice sorgente esplode
    - 4 l'eseguibile è enorme
  • Un defribrillatore come quello poteva andare bene hai tempi di Windows 95/98 dove i programmi andavano in crash molto facilmente portndosi spesso dietro anche il sistema operativo costringendo ad un reset forzato del PC.
    Oggi Microsoft ha migliorato parecchio i programmi si inchiodano molto meno rispetto al passato ed il Sistema operativo fortunatamente non si inchioda almeno per qunto riguarda lo stand alone in ambito server il discorso è un pochettino piu' complesso ma non si negano notevoli miglioramenti anche in ambito aziendale. Con Windows XP e Windows 7 la MS ha fatto notevoli passi avanti. Poi se ci tenete a criticare fatelo quanto volete tanto la fate sempre!!
    non+autenticato
  • ieri pomeriggio, mi era partita la connessione, windows 7 nel tentativo di riconnettersi a mandato in frezee exploer e non rispondeva piùTriste
    Sgabbio
    26177
  • - Scritto da: Franck
    > Un defribrillatore come quello poteva andare bene
    > hai tempi di Windows 95/98 dove i programmi
    > andavano in crash molto facilmente portndosi
    > spesso dietro anche il sistema operativo
    > costringendo ad un reset forzato del
    > PC.

    il. problema. e'. concettuale. e. NON. eliminabile. NON. e'. un. problema. di. sistema. operativo. tutti. i. soft/sistemi. operativi. ne. sono. e ne saranno. sempre. affetti.

    sei piu tranquillo, ora?
    non+autenticato
  • - Scritto da: Franck
    > Un defribrillatore come quello poteva andare bene
    > hai tempi di Windows 95/98 dove i programmi
    > andavano in crash molto facilmente portndosi
    > spesso dietro anche il sistema operativo
    > costringendo ad un reset forzato del
    > PC.
    > Oggi Microsoft ha migliorato parecchio i
    > programmi si inchiodano molto meno rispetto al
    > passato ed il Sistema operativo fortunatamente
    > non si inchioda almeno per qunto riguarda lo
    > stand alone in ambito server il discorso è un
    > pochettino piu' complesso ma non si negano
    > notevoli miglioramenti anche in ambito aziendale.
    > Con Windows XP e Windows 7 la MS ha fatto
    > notevoli passi avanti. Poi se ci tenete a
    > criticare fatelo quanto volete tanto la fate
    > sempre!!

    Penso che al MIT siano informati di questo, tutto sommato e' una delle migliori universita' al mondo e magari lo sanno anche senza consultare PI.
    L'articolo ovviamente non entra nel dettaglio della ricerca perche', da quanto si e' capito, e' piuttosto tecnica.   Il problema della terminazione di un'applicazione e' ben noto in Informatica ed e' chiaro che un'Universita' cosi' prestigiosa stia lavorando per trovare soluzioni teoriche/pratiche, magari parziali, al suddetto.
    Un risultato - ANCHE PARZIALE - in questo senso e' pacifico che avrebbe parecchie importanti implicazioni nel nostro settore, e NON SOLO per la terminazione dei programmi.
    non+autenticato
  • > Oggi Microsoft ha migliorato parecchio i
    > programmi si inchiodano molto meno rispetto al
    > passato ed il Sistema operativo fortunatamente
    > non si inchioda almeno per qunto riguarda lo
    > stand alone in ambito server il discorso è un
    > pochettino piu' complesso ma non si negano
    > notevoli miglioramenti anche in ambito aziendale.

    mio cuggino una volta è morto
    non+autenticato
  • Sul buon vecchio GWBasic: il comando CONT
    non+autenticato
  • - Scritto da: uno qualsiasi
    > Sul buon vecchio GWBasic: il comando
    > CONT

    >
    No dai! Ti faceva ripartire il programma dopo un break...
    non+autenticato
  • Appunto: se il programma andava in loop infinito, premevi control-c, lo fermavi, e lo facevi poi continuare.
    Alla peggio, uscivi dal break con un goto alla linea successiva

    Di fatto, puoi farlo anche adesso, con un debugger-disassembler. Probabilmente, il sistema descritto fa la stessa cosa, con la differenza che dovrebbe trovare da solo il ciclo che si è bloccato, e la prima istruzione fuori dal ciclo (cosa che, altrimenti, devi fare a mano guardando il disassemblato). Poi, blocchi il programma, sposti il puntatore alla prima istruzione successiva al loop, e riparti.

    Ma ... voglio vederti poi a usarlo, tale programma; ci saranno di sicuro memory leaks, operazioni non completate (e che il programma crede di aver completato), casini con lo stack pointer e altri errori simili. Il programma potrebbe piantarsi da un momento all'altro, o fornire risultati errati, o scrivere sul file sbagliato (magari era andato in tilt quando ti chiedeva il nome del file su cui salvare: sbloccandolo, salta tale parte, e quindi invece di chiederti il nome scrive sull'ultimo file usato).

    Insomma: un tool del genere concettualmente è interessante, ma rischia di fare più male che bene (soprattutto se lasciato in mano all'utonto, che dice "oooohhh, si è piantato! Dice di cliccare qui per sbloccarlo, cheffaccio, clicco? Massì!")
    non+autenticato
  • Sì, ma ti chiude il programma di brutto. Se non avevi salvato... vabbè, spero tu abbia messo l'autosave
    non+autenticato
  • - Scritto da: uno qualsiasi
    > Sì, ma ti chiude il programma di brutto. Se non
    > avevi salvato... vabbè, spero tu abbia messo
    > l'autosave

    Con Lion non servirà più salvare.
    non+autenticato
  • è vero, tanto si perdeva tutto comunque
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 9 discussioni)