Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Marco Aldrovandi ` E laureato in Ingegneria Elettronica. Attualmente si occupa di applicazioni safety critical per il settore ferroviario .
Limpaginazione automatica di questa rivista e realizzata al ` 100% con strumenti Open Source usando OpenOffice, Emacs, BHL, LaTeX, Gimp, Inkscape e i linguaggi Lisp, Python e BASH
For copyright information about the contents of Computer Programming, please see the section Copyright at the end of each article if exists, otherwise ask authors. Infomedia contents is 2005 Infomedia and released as Creative Commons 2.5 BY-NC-ND. Turing Club content is 2005 Turing Club released as Creative Commons 2.5 BY-ND. Le informazioni di copyright sul contenuto di Computer Programming sono riportate nella sezione Copyright alla ne di ciascun articolo o vanno richieste direttamente agli autori. Il contenuto Infomedia e 2005 Infome` dia e rilasciato con Licenza Creative Commons 2.5 BYNC-ND. Il contenuto Turing Club e 2005 Turing Club ` e rilasciato con Licenza Creative Commons 2.5 BY-ND. Si applicano tutte le norme di tutela dei marchi e dei segni distintivi. ` E in ogni caso ammessa la riproduzione parziale o totale dei testi e delle immagini per scopo didattico purch e vengano integralmente citati gli autori e la completa identicazione della testata. Manoscritti e foto originali, anche se non pubblicati, non si restituiscono. Contenuto pubblicitario inferiore al 45%. La biograa dellautore riportata nellarticolo e sul sito www.infomedia.it e di norma quella disponibi` le nella stampa dellarticolo o aggiornata a cura dellautore stesso. Per aggiornarla scrivere a info@infomedia.it o farlo in autonomia allindirizzo http://mags.programmers.net/moduli/biograa
primo piano
l 4 Luglio 1997 la sonda FIGURA 1 La sonda Pathfinder Automatica Pathfinder tocc il suolo di Marte dopo un viaggio durato 7 mesi. Latterraggio non present problemi, grazie al sistema di airbags che attut lo shock dellurto. Appena atterrata, la sonda inizi subito a trasmettere dati alle stazioni di ricezione sulla lontana Terra, tra cui una serie di eccezionali immagini del paesaggio Marziano. Quando inizi la raccolta dei dati metereologici per uno strano inconveniente inizi a portare preoccupazione su una missione che, fino a quel momento, si era svolta in modo assolutamente perfetto: periodicamente la sonda interrompeva linvio dei dati, per poi riprendere successivamente. Le prime indagini portarono ad attribuire la causa ad un Architettura della sonda reset periodico del computer di bordo. Non riuscendo a raccogliere dalla sonda su Marte sufficienti informaIn Figura 1 riportato un disegno della sonda zioni per risalire alla causa dellinconveniente, non Pathfinder; il software che ne assicurava il funzionarimase altra via che tentare di ricreare il problema nel mento aveva molto in comune con quello installato computer della sonda gemella presente, proprio a quenelle macchine automatiche presenti nelle nostre fabsto scopo, al Jet Propulsion Laboratory (JPL): la sonda briche: era cio un software real-time e multitasking. Si fu sottoposta a stimoli esterni il pi possibile simili a dice che unapplicazione real-time quando, in corriquelli a cui era sottoposta la sua gemella su Marte e spondenza di un particolare stimolo esterno, essa vennero registrati tutti i possibili dati relativi al funrisponder in un tempo predicibile (il vero tempo) zionamento interno del computer. mentre con il termine multitasking si intende unarchitettura software divisa in parti (dette processi o task) che vengono eseguite indipendentemente luna dallaltra; tale indipendenza per non assoluta ed Marco Aldrovandi maldrovandi@infomedia.it incontra il suo limite quando i vari processi devono condividere risorse comuni come ad esempio unarea laureato in Ingegneria Elettronica. Attualmente si occupa di di memoria, un canale di comunicazione o lo stesso applicazioni safety critical per il settore ferroviario. microprocessore. Chi progetta unarchitettura multita-
10
INFORMATICA
FIGURA 2
sking fa s che ciascun processo abbia un compito ben definito e diverso da quello degli altri processi: minore sar luso di risorse condivise, maggiore sar la frazione di tempo in cui i vari processi verranno eseguiti contemporaneamente luno allaltro, migliorando lefficienza complessiva del sistema. In Figura 2 viene mostrata larchitettura hardware della sonda Pathfinder: la CPU connessa ad un bus VME, al quale sono anche collegate direttamente la radio e lapparecchio per le riprese; il bus VME anche collegato ad un altro bus 1553 al quale sono a loro volta collegate la parte dedicata alla navigazione spaziale (cruise stage) e quella per latterraggio e le attivit al suolo (lander). Per essere utilizzato, il bus 1553 necessitava di un processo per la pianificazione (scheduling) delle attivit su di esso e di un altro processo per la distribuzione dei dati ai vari dispositivi utilizzatori. Come mostrato in Figura 3, lo scheduling doveva avvenire con una frequenza di 8 Hz, cio ad intervalli di 125 millisecondi.
essere letto e scritto da ogni processo e ha due stati: risorsa libera e risorsa occupata. Se un processo ha necessit di utilizzare la risorsa condivisa, legge il mutex e, se lo stato risorsa libera, lo cambier in risorsa occupata e inizier ad utilizzare la risorsa; se invece lo stato risorsa occupata, significa che un altro processo sta utilizzando la risorsa e al processo richiedente rimangono due scelte: rinunciare per riprovare successivamente oppure bloccarsi e mettersi in attesa che la risorsa si liberi... a questo punto i paragoni che possono essere fatti con molte situazioni della vita degli esseri umani vengono lasciati al lettore. La non disponibilit di una risorsa condivisa non lunica causa che pu bloccare un processo e metterlo in stato di attesa: ad un qualunque istante, il sistema operativo pu decidere che venuto il momento di fare eseguire un processo pi prioritario e quindi togliere al processo in esecuzione la risorsa pi preziosa, vale a dire il microprocessore: questa azione viene detta preemption ed i sistemi operativi che la attuano si dicono preemptive. Il fatto che un processo sia pi prioritario di un altro, non significa necessariamente che lattivit da esso svolta sia pi importante ma, dovendo assicurare un certo tempo di reazione (sistema real-time), non pu essere fermato da altri processi per pi di un certo tempo trascorso il quale il sistema operativo sospende il processo meno prioritario per occuparsi di quello con priorit maggiore. Se un sistema operativo invece non preemptive, lascer eseguire ogni processo fino a quando questo non si sospender spontaneamente lasciando modo agli altri di utilizzare il microprocessore.
Stato di attesa
Il processo di raccolta dei dati metereologici (processo ASI/MET) ed il processo di distribuzione dati sul bus 1553 comunicavano tramite un meccanismo messo a disposizione dal sistema operativo detto IPC (Inter Process Communication). Per assicurarsi che un solo processo per volta utilizzasse il canale, fu utilizzato un servizio del sistema operativo detto mutex (da mutua esclusione). Il mutex pu essere associato ad una risorsa condivisa, pu
FIGURA 3
11
primo piano
FIGURA 4
Linversione di priorit
Inversione di priorit
Nella sonda Pathfinder, il processo ASI/MET aveva priorit bassa mentre quello dedicato a distribuire i dati del bus 1553 aveva priorit alta. I tecnici del JPL lasciarono funzionare il computer della sonda per molti giorni, non riuscendo a risimulare lo strano comportamento che si stava osservando su Marte, fino a quando and in reset anche il computer sulla Terra e, dai dati registrati, si scopr che la causa era molto particolare: poteva accadere una successione di eventi come quella mostrata in Figura 4: il processo ASI/MET utilizza il canale dati IPC mettendolo dunque in stato di risorsa occupata usando il mutex. Prima che il processo ASI/MET abbia il tempo di liberare il canale, il sistema operativo attua una preemption sospendendolo per fare eseguire processi pi prioritari. Per la stessa ragione, ad un certo punto viene sospeso il processo in esecuzione perch venuto il momento di fare eseguire quello dedicato alla distribuzione dei dati del bus 1553. Tale processo necessita per di utilizzare il canale IPC e quindi, trovandolo occupato, si sospende nuovamente, facendo riprendere lesecuzione del processo a media priorit prima sospeso. Quando viene fatto eseguire il processo ad alta priorit dedicato allo scheduling delle attivit sul bus 1553 (sono scaduti i 125 millisecondi), esso trover che il processo di distribuzione dati non ancora terminato: il sistema di autodiagnosi interpreta questo come funzionamento non ammissibile e dunque comanda il reset del computer osservato da Terra. 12
Comportamenti come questo vengono detti inversione di priorit: infatti un processo a bassa priorit (il processo ASI/MET) tiene bloccato un processo ad alta priorit (il processo di distribuzione dati). Nei sistemi operativi multitasking questo problema ben noto e viene risolto facendo ereditare le priorit: in un caso come quello prima citato, il processo a bassa priorit eredita temporaneamente lalta priorit del processo che sta bloccando, allo scopo di sbloccarlo prima possibile. Il sistema operativo usato sulla sonda Pathfinder poteva realizzare questa ereditariet, ma tale funzione era stata disabilitata in quanto ritenuta fonte di un inutile aumento di complessit del sistema: molto pi difficile infatti prevedere in modo rigoroso i tempi di risposta di un sistema nel quale le priorit dei processi possono variare nel tempo. Ora che la probabile causa era stata individuata, rimaneva da risolvere un piccolo problema: come cambiare questa impostazione in un computer che si trovava a milioni di chilometri di distanza. Il problema fu risolto grazie alla possibilit di trasmettere un nuovo software da Terra. Una volta eseguito lintervento, il problema cess di presentarsi. Pur essendo avvenuto in un contesto particolarissimo, questo caso presenta molti spunti di riflessione per i normali programmatori terrestri: si pu cio pensare a cosa ha reso pi facile lindividuazione di un problema cos sfuggente e cosa ne ha reso possibile la correzione anche in una situazione estrema; infine, e questa la parte pi difficile, si pu anche riflettere su cosa ha causato il problema.
Simulazione e registrazione
Senza dubbio, il problema non sarebbe stato individuato se non fossero stati disponibili una macchina esattamente uguale presente in laboratorio; un completo sistema di registrazione di tutto quanto avveniva allinterno del sistema, fino ad arrivare allo stato di ogni processo in ogni istante. Chiunque abbia installato un sistema software gestionale o una macchina automatica presso un cliente sa quanto siano importanti le risorse sopra elencate; se si vuole stabilire un ordine di importanza, la seconda risulta anche pi importante della prima: corredare la propria applicazione di un completo e dettagliato sistema di registrazione (logging) degli eventi risulta anche pi importante di poter disporre di un sistema gemello sul quale tentare di risimulare il comporta-
INFORMATICA
mento anomalo riscontrato sul campo, in quanto esistono stimoli esterni e situazioni particolari che sono difficili o addirittura impossibili da simulare in laboratorio, soprattutto se si tiene conto che non si sa qual la situazione che origina il problema. Un sistema di logging pu anche essere tenuto sempre attivo sul campo, dove pi probabile che il comportamento anomalo si ripresenti. Naturalmente, vi sono controindicazioni e precauzioni da prendere: un sistema di logging interno rischia infatti di degradare le prestazioni del sistema aumentando troppo i tempi di risposta. Una possibile soluzione pu essere quella di realizzare un sistema di logging normalmente disabilitato ma abilitabile nel caso si debba investigare su un comportamento anomalo; questo tipo di soluzione introduce per una variazione nel sistema sotto esame e pu causare anche il non ripresentarsi del problema mentre il sistema di logging abilitato. I bug software che hanno la spiacevole caratteristica prima citata vengono detti Heisenbugs, dal noto principio di indeterminazione di Heisemberg. Ove possibile, la soluzione migliore quella di predisporre un sistema di logging esterno, quale ad esempio uno sniffer su una linea di comunicazione: esso pu essere tenuto sempre attivo e non altera minimamente le prestazioni del sistema (se si trascurano gli effetti quantistici...); una soluzione del genere non per applicabile per registrare il comportamento del sistema operativo. costose; in questi casi, disporre di un sistema gemello dimostra tutta la sua necessit.
Accessibilit
Aver scoperto la causa del problema nella sonda Pathfinder sarebbe stato assolutamente inutile se non ci fosse stato modo di correggerlo. In questo caso, stato determinante poter disporre di un sistema con un elevato grado di accessibilit. Moltissime attivit che in laboratorio sembrano immediate, come ad esempio il cambiamento di un parametro di configurazione o la programmazione di un componente, sul campo possono risultare assolutamente impossibili o per la mancanza di un certo strumento o semplicemente perch non al momento disponibile una presa di corrente. Tra le tante, si consideri ad esempio proprio lattivit svolta da Terra verso la sonda Pathfinder, cio il caricamento e lesecuzione di software. Nel caso delle applicazioni realizzate per PC ormai prassi comune scaricare dal sito internet della software-house i programmi correttivi (patches) che, solitamente, sono auto-installanti. Anche in questo caso per vi possono essere problemi di sicurezza, legati alla certificazione dellautenticit della patch. Per le applicazioni embedded, tutto pi difficile: il software pu essere memorizzato su un componente programmabile, ed esempio una EPROM, per accedere alla quale occorre smontare parzialmente o totalmente talune parti meccaniche e, daltra parte, facilitare laccesso pu significare maggiore debolezza agli urti e ad altri fattori ambientali come pioggia e polvere. Il progetto deve essere quindi orientato anche a facilitare la soluzione dei problemi che si presentano dopo linstallazione (post-shipment problems).
Processi di diversa
primo piano
FIGURA 5
prioritaria rispetto ad altre attivit: tale scelta, a posteriori, non pu che essere considerata positivamente visto il successo della missione. Purtroppo per questo non sempre vero e chiunque si sia occupato di test sa che quel fastidioso e sfuggente difetto che si presentato una sola volta in laboratorio e che non si pi riusciti a risimulare (definito, in gergo, fantasma) si ripresenter sicuramente dopo linstallazione in impianto. In questo caso, lunica possibile difesa installare un sistema robusto (magari con programmazione difensiva) e progettato pensando ai post-shipment problems, come ben sapevano i progettisti di Pathfinder.
Conclusioni
Il caso della sonda Pathfinder pu essere visto come un esempio estremo della situazione in cui si ha un problema su una macchina o un impianto al quale non si pu accedere direttamente. Si visto che problemi del genere non possono essere risolti se non si dispone di una sufficiente quantit di informazioni su quanto accaduto o sta accadendo e se non possibile agire a distanza in modo da risolvere il problema. Tali requisiti devono essere assolutamente considerati in fase di progetto. Grande attenzione deve poi essere riservata alle condizioni di test, spesso testare un sistema anche al di sopra dei requisiti previsti rappresenta un costo aggiuntivo trascurabile ma pu mettere in risalto problemi che diversamente sarebbe difficile individuare o che, in condizioni di test pi leggere, si presentano sotto forma di fantasmi.
Logging e accessibilit
Linsegnamento che si pu trarre da questo che occorre fare estrema attenzione alle condizioni di test: una volta creato lambiente di collaudo, aumentare il carico elaborativo simulato ha di solito un impatto economico trascurabile ma pu dare informazioni molto utili. Durante i test comunque si osserv qualche caso di reset ma lindagine venne ritenuta meno 14