Corso di SISTEMI OPERATIVI

Presentazione sul tema: "Corso di SISTEMI OPERATIVI"— Transcript della presentazione:

1 Corso di SISTEMI OPERATIVI
I Sistemi Operativi Real-Time Corso di SISTEMI OPERATIVI I Sistemi Operativi Real-Time Concetti fondamentali Professore: William Fornaciari © Luca Massoletti © A/A 2000/2001 Luca Massoletti

2 Corso di SISTEMI OPERATIVI
I Sistemi Operativi Real-Time Sommario Tempo reale e parallelismo Modelli implementativi di parallelismo virtuale Modello a processi sequenziali comunicanti Scheduling temporale – Preemption Interruzioni – Priorità – Annidamento Competizione e cooperazione Primitive I Sistemi Operativi Real-Time © A/A 2000/2001 Luca Massoletti © A/A 2000/2001 Luca Massoletti

3 Tempo reale e parallelismo
In un ambiente di elaborazione in tempo reale l'esecuzione di un lavoro si può considerare corretta solo se sono rispettati certi vincoli temporali. In un tale sistema il carico di lavoro è scomponibile in tre componenti: Attività costituite da azioni periodiche. Azioni aperiodiche (generalmente sporadiche). Attività di sottofondo I Sistemi Operativi Real-Time © Luca Massoletti

4 Tempo reale e parallelismo Lo scopo temporale
Lo scopo temporale di un'azione è l'intervallo di tempo tra l'istante in cui si verifica l‘Evento attivante e l'istante in cui tale attività deve essere completata chiamato Deadline. I Sistemi Operativi Real-Time © Luca Massoletti

5 Tempo reale e parallelismo Overlapping
Se alcune attività hanno azioni i cui scopi temporali presentano sovrapposizioni (overlapping), allora tali attività vengono dette concorrenti. Se invece non vi sono scopi temporali sovrapposti le attività vengono dette sequenziali. Si noti che un'elaborazione ad attività concorrenti non è detto che sia necessariamente di tipo real-time. I Sistemi Operativi Real-Time © Luca Massoletti

6 Tempo reale e parallelismo Parallelismo
Un processo sequenziale è un'attività internamente sequenziale caratterizzata da un proprio contesto, cioè dall'insieme delle risorse ad essa allocate, con i rispettivi stati. Tali risorse possono essere attive (processori) o passive (periferiche, memoria, dati, ecc.). Un processo, per essere eseguito, richiede una risorsa attiva ed eventualmente delle risorse passive. Il parallelismo tra diverse elaborazioni è la capacità di iniziare una nuova azione anche se altre sono già in corso. I Sistemi Operativi Real-Time © Luca Massoletti

7 Tempo reale e parallelismo Preemption
Siano: TDi la durata dello scopo temporale dell'azione i-esima TEi il massimo tempo di esecuzione netto dell'azione i-esima   Condizione sufficiente perché sia richiesto un parallelismo di esecuzione è che esistano almeno due eventi tra loro aperiodici, che iniziano gli scopi temporali rispettivamente dell'azione i e j, per cui sia: TDi < TEi + TEj Condizione sufficiente perché si possa evitare la preemption, se TDj è la più breve deadline, è che sia: ∑ TEi < TDj. I Sistemi Operativi Real-Time © Luca Massoletti

8 Tempo reale e parallelismo Parallelismo fisico
Un parallelismo fisico è ottenibile se sono disponibili tanti processori (multiprocessing), quante sono le attività potenzialmente concomitanti. Ciò implica un'assegnazione (scheduling) spaziale delle attività alle risorse. Ogni risorsa rimane inattiva (idle) per tutto il tempo in cui non è richiesto lo svolgimento di azioni dell'attività assegnatale. Un'applicazione non è fisicamente realizzabile se si ha, per almeno un'azione: TEi > TDi. I Sistemi Operativi Real-Time © Luca Massoletti

9 Tempo reale e parallelismo Parallelismo virtuale
Il parallelismo virtuale si ottiene con l'assegnazione distribuita nel tempo delle risorse alle azioni in corso durante intervalli di tempo interni ai loro scopi temporali (multitasking). Dovrà quindi esserci uno scheduling temporale. Definiamo ora il coefficiente di utilizzazione del processore: U = ∑i=1..n (TEi / TAi) n = numero di azioni potenzialmente richieste al processore TEi = tempo di esecuzione netto dell'azione i-esima TAi = intervallo tra le attivazioni dell'azione i-esima I Sistemi Operativi Real-Time © Luca Massoletti

10 Tempo reale e parallelismo Parallelismo misto
Infine, si parla di parallelismo misto se abbiamo più processori, ognuno dei quali esegue più attività in parallelismo virtuale. Con un unico processore, se U < 1 ed ogni azione è contenuta nel proprio scopo temporale, si ottiene un effetto "equivalente" a quello ottenibile da diversi processori in parallelo. Infatti, le specifiche temporali richieste riguardano solo l'azione conclusiva di emissione del risultato finale e non specificano il comportamento nelle fasi intermedie. I Sistemi Operativi Real-Time © Luca Massoletti

11 Tempo reale e parallelismo
Occorre dire che il parallelismo virtuale è molto importante anche nei sistemi multiprocessore, ed è molto usato per le seguenti ragioni: Diventano sempre più economici processori molto più potenti di quanto richiesto da una singola attività e che quindi sarebbero poco sfruttati da una sola attività. Le attività assegnate ad uno stesso processore sono favorite nelle reciproche sincronizzazioni e comunicazioni in termini di semplicità ed efficienza rispetto a quelle assegnate a processori diversi I Sistemi Operativi Real-Time © Luca Massoletti

12 Modelli implementativi di parallelismo virtuale
Queste tecniche implementative sono realizzate dal nucleo (kernel) del Sistema Operativo preposto alla gestione dei processi. Esse sono classificabili in tre modelli: Time-driven. Execution-driven multitasking. Event-driven multitasking. I Sistemi Operativi Real-Time © Luca Massoletti

13 Time-driven Le informazioni in ingresso possono essere ottenute da una osservazione periodica (campionamento) di stati continui o discreti. Nell'approccio time-driven ogni attività è implementata come una successione di azioni che consistono nella valutazione, ripetuta ad ogni campionamento, di una stessa funzione dei valori catturati in ingresso (Ii), di uno stato interno (Si), e che produce un valore di uscita (Oi), e l'eventuale nuovo valore dello stato interno (Si+1). Questa modellizzazione corrisponde ad una rete sequenziale sincrona, o, equivalentemente, ad una funzione di trasferimento a tempo discreto. I Sistemi Operativi Real-Time © Luca Massoletti

14 Time-driven Supponiamo che si debbano eseguire le attività concorrenti A, B e C con lo stesso periodo di campionamento. L'esecuzione delle azioni è organizzata in questo modo: All'istante t0 si utilizzano i valori I0 e S0 per eseguire le azioni a0, b0, c0 che producono i valori O0 e S1 All'istante t1 si utilizzano i valori I1 e S1 per eseguire le azioni a1, b1, c1 che producono i valori O1 e S2 I Sistemi Operativi Real-Time © Luca Massoletti

15 Time-driven All'istante ti si utilizzano i valori Ii e Si
per eseguire le azioni ai, bi, ci che producono i valori Oi e Si+1 E' time-driven perché tutte le azioni sono eseguite solo in base ad eventi temporali. Qui gli eventi esterni giocano solo un ruolo passivo, e possono essere rilevati deducendoli dalle differenze dei valori campionati in ingresso. E' dominante il concetto di stato. Lo scheduling delle azioni è statico (off-line), e non c'è preemption. I Sistemi Operativi Real-Time © Luca Massoletti

16 Time driven: pregi I pregi di questo modello sono:
la semplicità. Il supporto runtime è costituito da un sistema operativo molto ridotto che si limita alla lettura delle porte in ingresso, alla scrittura delle porte in uscita e alla gestione di un temporizzatore di attivazione ciclica. la predicibilità. E' facile verificare se il fattore di utilizzo è < 1 (tempi di esecuzione molto regolari e occupati ad intervalli regolari). Con tale ipotesi, se Tp è il periodo di ripetizione ciclica, il tempo di risposta del sistema è Tr < 2 * Tp. Infatti il caso peggiore si ha quando un ingresso cambia subito dopo essere stato campionato all'inizio del ciclo i. Alla fine di tale ciclo le uscite corrisponderanno ancora al vecchio valore dell'ingresso, mentre le uscite terranno conto del nuovo valore solo alla fine del ciclo i+1. I Sistemi Operativi Real-Time © Luca Massoletti

17 Time driven: difetti I difetti di questo modello sono invece:
Tutte le informazioni di ingresso, indipendentemente dalla loro urgenza o criticità, godono dello stesso trattamento temporale. Quindi la cadenza sarà imposta dalle attività più critiche, con un cattivo sfruttamento della CPU. Tutte le attività devono essere ricondotte alla forma di ripetizione ciclica degli stessi calcoli. I Sistemi Operativi Real-Time © Luca Massoletti

18 Execution-driven multitasking.
Su richiesta si commuta dal contesto di un'attività a quello di un'altra. Si lascia al programmatore applicativo la possibilità, e quindi la responsabilità, di invocare questa commutazione di contesto. Anche qui gli eventi esterni sono passivi. Non vi è alcuna garanzia di rispetto di eventuali vincoli temporali. Per questo motivo questa tecnica è solo raramente utilizzata in applicazioni con requisiti di tempo reale "lasco".  I Sistemi Operativi Real-Time © Luca Massoletti

19 Event-driven multitasking
Il sistema è reattivo perché reagisce agli stimoli costituiti da eventi esterni, i quali attivano (trigger) le esecuzioni di certe azioni. Le attività sono eseguite da procedure software ben aggregate internamente e tra loro ben disaccoppiate, ed assumono la veste di processi, ognuno dotato di un proprio contesto. Qui gli eventi esterni giocano un ruolo attivo, di solito mediante meccanismi di generazione di richieste di interruzione, e ciò costituisce la caratteristica qualificante di questo approccio. Occorre adottare una politica di scheduling sia delle azioni di servizio alle interruzioni che dei processi. I Sistemi Operativi Real-Time © Luca Massoletti

20 Considerazioni sulle tecniche presentate
L'approccio event-driven è quello più generale. Un'applicazione complessa potrà comprendere: Un sottoinsieme di attività cicliche di controllo e supervisione (gestione di tipo time-driven). Alcune attività di tipo reattivo e con vincoli temporali sui tempi di risposta (gestione di tipo event-driven). Delle attività di sottofondo senza particolari vincoli temporali e che quindi utilizzano i tempi lasciati liberi dalle attività precedenti (gestione execution-driven). Ci concentreremo ora sull'ultimo approccio, quello event-driven. I Sistemi Operativi Real-Time © Luca Massoletti

21 Task e threads I processi sono attività dotate di un proprio contesto che competono per l'uso della CPU e che possono tra loro condividere codice, dati ed eventualmente altre risorse. Distinguiamo tra due tipi di processi, i task ed i threads. I task sono processi dotati di un contesto proprio che comprende anche aree di memoria proprie. Ogni task è ottenuto da una separata operazione di collegamento (linking). I threads sono processi dotati di un proprio stack, ma che possono condividere variabili globali, essendo stati collegati nell'ambito della stessa operazione di linking. I Sistemi Operativi Real-Time © Luca Massoletti

22 Task e threads Un task può contenere al suo interno più threads.
Durante la loro evoluzione, i processi sono caratterizzati da uno stato interno e da uno stato esterno. Il primo è gestito dal processo stesso eseguendo istruzioni del set base ed è descritto dal valore del Program Counter, dei registri e delle sue variabili private. Il secondo ne descrive la situazione rispetto all'ambiente complessivo ed è gestito dal Sistema Operativo, in occasione della esecuzione di primitive o di interrupt. I Sistemi Operativi Real-Time © Luca Massoletti

23 Stati dei processi Inesistente. Il codice principale non è stato ancora caricato nella memoria operativa. Dormiente. Presente in memoria ma non ancora dotato di un contesto completo, cioè non ancora preso in carico dal sistema operativo. Pronto. Può essere eseguito, ed è in attesa della CPU. In esecuzione. Dispone della CPU. Nei sistemi preemptive ha priorità non inferiore a quella di ogni processo pronto. Può essere in esecuzione nel modo utente o nel modo sistema. Nel primo caso sta eseguendo procedure applicative, nel secondo sta eseguendo procedure appartenenti al sistema operativo che costituiscono servizi che esso mette a disposizione dei processi. I Sistemi Operativi Real-Time © Luca Massoletti

24 Stati dei processi Interrotto. E' latente perché interrotto da una richiesta di servizio di interrupt, la quale può produrre eventi o risorse che possono portare nello stato ready altri processi che ne erano in attesa. In attesa di evento. E' destinato a reagire ad un evento che deve ancora verificarsi, o sta aspettando risorse non ancora disponibili. Un processo può essere in attesa disgiuntiva di diversi eventi, ad esempio evento OR scadenza temporale (time out). Sospeso. Non compete più per l'uso di risorse o della CPU. Un processo può passare volontariamente in questo stato oppure esservi collocato di forza dal sistema operativo in seguito ad eccezioni irrecuperabili. I Sistemi Operativi Real-Time © Luca Massoletti

25 Come gli eventi producono transizioni di stato
 Le transizioni di stato possono essere causate da: Eventi interni. Eventi esterni. Eventi temporali. I Sistemi Operativi Real-Time © Luca Massoletti

26 Diagramma stati-transizioni
I Sistemi Operativi Real-Time © Luca Massoletti

27 Diagramma stati-transizioni
Caricamento in memoria. Fase non necessaria per quei sistemi dotati di memorie non volatili e che spesso sono privi di memorie di massa, come è il caso di molti controllori e sistemi embedded. Creazione. Funzione seguita dal sistema operativo autonomamente in fase di inizializzazione, o su richiesta di un processo in esecuzione. Viene creato il contesto del processo, consistente in un'area di stack e un descrittore dinamico con opportuna inizializzazione. Assegnazione della CPU. Preceduta da una fase di scelta del processo da attivare tra tutti quelli pronti (scheduling). I Sistemi Operativi Real-Time © Luca Massoletti

28 Diagramma stati-transizioni
Invocazione di primitiva. Il processo in esecuzione invoca uno dei servizi messi a disposizione dal sistema operativo. In alcuni sistemi questa invocazione è implementata mediante istruzioni di software interrupt. I servizi possono completarsi subito oppure portare il processo in stato di attesa degli eventi che consentano la conclusione del servizio richiesto. Ritorno da primitiva non bloccante. Avviene se il servizio è stato completato e non ha comportato il passaggio allo stato di pronto di un processo più prioritario di quello invocante. Interruzione. Al termine dell'istruzione corrente (o del gruppo di istruzioni non interrompibili) quando nel frattempo sia stata segnalata una richiesta di interruzione e la CPU sia abilitata ad onorare tale richiesta. Questa transizione si verifica nello stato in esecuzione, sia in modo utente sia in modo sistema. I Sistemi Operativi Real-Time © Luca Massoletti

29 Diagramma stati-transizioni
Ritorno da interruzione. A conclusione di un servizio ad interruzione che non abbia posto in stato di pronto processi più prioritari di quello interrotto, che quindi riprende la propria esecuzione "ignaro" dell'interruzione. Preemption. Nell'ambito di un servizio di risposta a richiesta di interruzione, durante il quale venga portato nello stato di pronto un processo più prioritario di quello interrotto, che a sua volta viene posto nello stato di pronto.  Eccezione fatale. Le "eccezioni" (anomalie in esecuzione) vengono rilevate con diversi meccanismi che passano il controllo al sistema operativo. Se questo non è in grado di "recuperarle" deve forzare la sospensione del processo responsabile, di solito quello in esecuzione. I Sistemi Operativi Real-Time © Luca Massoletti

30 Diagramma stati-transizioni
Richiesta di attesa di risorsa o evento. Quando il servizio invocato comporta la richiesta di attesa di una risorsa non disponibile o di un evento il processo richiedente viene posto in stato di attesa. Occorrenza di un evento. Quando si verifica un evento atteso, la disponibilità di una risorsa richiesta o una scadenza temporale attesa o di time-out, il processo interessato viene posto nello stato di pronto. Richiesta di sospensione. Un processo può inoltrare al sistema operativo la richiesta di terminare la propria esecuzione. I Sistemi Operativi Real-Time © Luca Massoletti

31 Scheduling temporale – Preemption
L'operazione di scheduling consiste nella scelta di quale processo mandare in esecuzione. CHI. L'operazione viene eseguita dal sistema operativo, quando esso ha il controllo della CPU. QUANDO: In seguito all'invocazione di una primitiva da parte del processo in esecuzione. In occasione di risposte a richieste di interruzione. Un caso particolare è costituito dall'interruzione del RTC (real-time clock). COME. Vi sono una serie di algoritmi di scheduling. I Sistemi Operativi Real-Time © Luca Massoletti

32 Non-preemptive scheduling
Al termine del servizio di ogni interruzione il controllo viene ceduto al processo interrotto mentre era in esecuzione. Quindi ogni processo in esecuzione rimane tale fino a quando volontariamente invoca servizi del sistema operativo. Si ha così una notevole semplificazione nei rapporti fra i processi, visto che i cambiamenti di contesto vengono effettuati solo in occasione di chiamate al sistema operativo. Inoltre viene minimizzato l'overhead associato ai cambiamenti di contesto, quindi con un miglior sfruttamento delle risorse e un miglior throughput. Il grosso limite di questo approccio è che le prestazioni in tempo reale sono responsabilità del programmatore di processi e non sono garantite da sistema operativo. I Sistemi Operativi Real-Time © Luca Massoletti

33 Preemptive scheduling
E' la soluzione comunemente adottata. Ogni volta che assume il controllo, il sistema operativo individua il processo più opportuno da attivare, in base alle scadenze temporali da rispettare per le varie elaborazioni. La preemption si ha quando, al ritorno da un interrupt hardware, l'esecuzione non torna al processo interrotto, ma ad uno più prioritario diventato pronto in conseguenza del servizio dell'interrupt. Quindi la preemption può verificarsi in tutte le parti del processo in cui è abilitato l'interrupt. I Sistemi Operativi Real-Time © Luca Massoletti

34 Preemptive scheduling
Affinché le mutue interazioni fra i processi siano corrette: E' necessario rendere atomiche (non interrompibili) le regioni critiche. Tutte le funzioni eseguibili da diversi processi devono essere implementate in modo rientrante. Con gestione degli interrupt con annidamento, tutti i vettori di interrupt devono passare attraverso il sistema operativo e non possono essere connessi direttamente alle routine di risposta scritte dal programmatore applicativo. I Sistemi Operativi Real-Time © Luca Massoletti

35 I piu diffusi algoritmi di scheduling temporale: obiettivi
Gli obiettivi dello scheduling sono diversi: Semplicità dello scheduler. Massimizzazione del throughput del sistema. Massimizzazione della predicibilità temporale. Minimizzazione del rischio di anomalie gravi. I Sistemi Operativi Real-Time © Luca Massoletti

36 Algoritmi di scheduling: Round Robin
I processi sono collocati in una sequenza fissa che viene ciclicamente scandita. Ad ogni operazione di scheduling si incrementa l'indice del vettore di processi e viene selezionato per l'attivazione il primo trovato pronto. Giunti in fondo al vettore si riprende dalla prima posizione. Ad un processo può essere assegnato un quanto di tempo (time slice), al termine del quale il processo, se è ancora in esecuzione, subisce una preemption. Ciò consente una migliore predicibilità dei casi peggiori dei tempi di esecuzione dei singoli processi. Infatti i tempi massimi di esecuzione possono essere calcolati pensando che ad ogni processo è concessa la frazione 1/N della potenza di calcolo. I Sistemi Operativi Real-Time © Luca Massoletti

37 Round Robin: pregi e difetti
Questo algoritmo ha come pregi: Semplicità e rapidità di esecuzione. Nessun processo rischia di attendere indefinitamente (starvation). I suoi difetti sono invece: Nessuna garanzia di tempo reale (tranne che con il time-slicing). Non si distingue tra attività più o meno importanti o urgenti. I Sistemi Operativi Real-Time © Luca Massoletti

38 Algoritmi di scheduling: FIFO
FIFO. Quando i processi diventano pronti sono collocati in fondo ad una coda FIFO. Viene estratto per l'attivazione il primo processo nella coda. I Sistemi Operativi Real-Time © Luca Massoletti

39 FIFO: pregi e difetti Pregi: Semplicità e rapidità di esecuzione.
No starvation. Difetti: Nessuna garanzia di tempo reale. Non si distingue tra attività più o meno importanti o urgenti. I Sistemi Operativi Real-Time © Luca Massoletti

40 Algoritmi di scheduling: Fixed Priority
Ad ogni processo è assegnato staticamente un livello di priorità. I processi pronti sono in una coda ordinata per priorità decrescenti. Viene attivato il processo in testa alla coda. Se più processi hanno la stessa priorità, si utilizza per essi il criterio FIFO. I Sistemi Operativi Real-Time © Luca Massoletti

41 Fixed Priority: pregi e difetti
Semplicità e rapidità di esecuzione. Si tiene conto dell'importanza relativa dei diversi processi. Difetti: La garanzia di tempo reale è affidata alla buona attribuzione delle priorità da parte del progettista applicativo. Fasi di attività di uno stesso processo con diversa importanza vengono trattate allo stesso modo. Problema dell'inversione di priorità. Ad esempio un processo A ad alta priorità sta attendendo una risorsa impegnata da un processo a bassa priorità B. Tutti i processi a priorità media M passeranno davanti al processo, in tal modo ritardandone il rilascio della risorsa e quindi ritardando A (che invece dovrebbe essere privilegiato rispetto ai processi M). I Sistemi Operativi Real-Time © Luca Massoletti

42 Algoritmi di scheduling: Rate monotonic
E' un metodo a priorità fissa usato quando i processi sono caratterizzati da: Esecuzione periodica con periodo Ti. Deadline costituita dal termine del periodo Ti. Tempo di esecuzione netto Ci uguale, o limitato superiormente, in ogni ciclo. Viene garantito il rispetto delle scadenze di tutti i processi se: Le priorità sono assegnate in ordine inverso alle durate dei periodi Ti. Lo scheduling è di tipo preemptive. Il coefficiente di utilizzazione della CPU, dato dall'espressione ∑ Ci / Ti, è minore di circa 0.7. Questo algoritmo è ottimo. I Sistemi Operativi Real-Time © Luca Massoletti

43 Algoritmi di scheduling: Earliest deadline.
La priorità viene assegnata dinamicamente ai processi. Il processo più prioritario è quello che ha la deadline più vicina nel tempo, che ovviamente lo scheduler deve conoscere. Anche questo algoritmo è ottimo. I Sistemi Operativi Real-Time © Luca Massoletti

44 Algoritmi di scheduling: Minimum laxity
Qui viene considerato più urgente il processo meno dilazionabile. La laxity (dilazionabilità) di un processo è la differenza tra la distanza dalla deadline ed il tempo netto di elaborazione ancora da eseguire. Perciò qui lo scheduler deve conoscere anche i tempi di esecuzione dei processi e tenere aggiornato il conto del tempo di esecuzione rimanente. Anche questo algoritmo è ottimo. I Sistemi Operativi Real-Time © Luca Massoletti

45 Ricordiamo che un algoritmo è ottimo quando garantisce il rispetto di tutte le scadenze in tutte le situazioni in cui ciò è possibile (feasible). I Sistemi Operativi Real-Time © Luca Massoletti

46 Esempio di scheduling a priorità in cui lo stato della coda cambia a seguito dell'entrata in attesa di un processo : si vede prima la condizione iniziale della coda e poi lo stato della coda dopo che il processo A è entrato nello stato di attesa. I Sistemi Operativi Real-Time © Luca Massoletti

47 Interruzioni – Priorità - Annidamento
 Nella maggior parte delle applicazioni di automazione il servizio alle interruzioni è fortemente dipendente dai particolari dispositivi e quindi non può essere eseguito da procedure standard del sistema operativo. E' il programmatore applicativo che deve farsi carico della stesura delle relative routine di risposta (ISR). Un approccio implementativo può essere il seguente: Il sistema operativo si fa carico della fase iniziale e conclusiva di tutte le routine di risposta, con porzioni di codice standard. I processi applicativi possono chiedere al sistema operativo, tramite opportune primitive, di abilitare particolari livelli di interruzione ed agganciare ad essi specifiche routine applicative. Tali routine dovranno essere brevi, limitate nell'accesso alle risorse, scritte in modo da evitare situazioni di blocco, con chiamate di sole funzioni rientranti, ecc. I Sistemi Operativi Real-Time © Luca Massoletti

48 Livelli di annidamento
Nelle applicazioni in tempo reale è necessario tener conto del diverso grado di urgenza associato ai diversi servizi, cercando di ridurre la latenza dei servizi più urgenti. Per far ciò bisogna consentire un annidamento dei servizi di risposta. Una risposta ad una interruzione può a sua volta essere interrotta da interruzioni più prioritarie, e solo quando essa dichiara concluso il suo compito possono essere accettate interruzioni di pari o inferiore priorità. I Sistemi Operativi Real-Time © Luca Massoletti

49 Competizione e cooperazione
 Nelle applicazioni di automazione i processi presentano più o meno strette relazioni di cooperazione. In questo caso un unico job è scomposto in diversi processi (tipicamente di tipo thread) principalmente per consentire la concorrenza (parallelismo virtuale) necessaria per supportare interazioni in tempo reale con fenomeni asincroni. Ad esempio un processo gestisce un'interfaccia di acquisizione dati, un altro realizza funzioni di controllo, un altro interagisce con l'operatore ed infine uno mantiene le comunicazioni con sistemi remoti. I Sistemi Operativi Real-Time © Luca Massoletti

50 Temporizzazione – Sincronizzazione – Mutua esclusione
La temporizzazione consiste nell'eseguire particolari azioni in particolari istanti di tempo assoluto o relativo rispetto ad altri istanti. La sincronizzazione serve a garantire che vengano rispettati i vincoli di precedenza tra le azioni che producono e le azioni che utilizzano informazioni, in modo da realizzare un parziale ordinamento temporale tra azioni. La mutua esclusione serve a garantire che siano svolte in modo corretto operazioni che richiedono l'uso di risorse che in ogni istante possono essere in uso ad un solo processo. Esempi di risorse che richiedono mutua esclusione possono essere la stampante, aree di dati in memoria, procedure e funzioni non rientranti. I Sistemi Operativi Real-Time © Luca Massoletti

51 Temporizzazione – Sincronizzazione – Mutua esclusione
Queste tre funzioni possono essere realizzate in due modi: Inglobate in un linguaggio di programmazione appositamente progettato per la concorrenza rendendole così in parte invisibili al programmatore. Eseguite come primitive del sistema operativo che il programmatore invoca in modo esplicito. Questo è l'approccio più diffuso I Sistemi Operativi Real-Time © Luca Massoletti

52 Primitive Sono i servizi che il sistema operativo mette a disposizione dei processi. Una buona parte delle attività del sistema operativo vengono svolte all'interno di queste procedure. Le rimanenti funzionalità sono attivate dalle interruzioni del real-time clock e delle interfacce hardware. Vediamo ora una rassegna delle primitive tipicamente previste per applicazioni di elaborazione in tempo reale. I Sistemi Operativi Real-Time © Luca Massoletti

53 Primitive generali Create (Processo). Processo è un descrittore statico, strutturato a record, che contiene i valori degli attributi iniziali del processo, cioè priorità, ampiezza dell'area di stack richiesta, entry point, eventuali risorse private permanenti. La primitiva assegna al processo un suo contesto e inizializza un descrittore dinamico, ponendo il processo nello stato di Pronto. Poi o ritorna al processo chiamante o chiama lo scheduler. Suspend. Pone il processo invocante nello stato Sospeso e poi cede il controllo allo scheduler. I Sistemi Operativi Real-Time © Luca Massoletti

54 Primitive di temporizzazione
Abs_Wait (abs_time). Pone il processo chiamante in stato di attesa, e associa al suo descrittore dinamico il valore abs_time. Poi cede il controllo allo scheduler. Sotto risposta a interrupt di RTC il sistema operativo mette nello stato Pronto il processo invocante quando t = abs_time. Rel_Wait (rel_time). Come prima. Qui però l'attesa è di un intervallo di tempo, di durata rel_time. Cyc_Wait (period). Riattivazione ciclica e periodica ad ogni intervallo pari a period. _ tout (..., tout_time). L'attesa con time-out è associata all'attesa di altri eventi. Il processo invocante chiede di essere comunque svegliato dopo il tempo tout_time, se non si verifica l'evento atteso. I Sistemi Operativi Real-Time © Luca Massoletti

55 Procedure di sincronizzazione
L'approccio tipico consiste di primitive di basso livello che si basano sull'uso di semafori. Wait (semaphore [, tout]). Decrementa semaphore. Se poi semaphore è > 0 torna al processo invocante, altrimenti mette il processo nello stato di attesa, indicando nel suo descrittore dinamico il semaforo su cui è in attesa e il tempo di tout eventuale. Sotto risposta a RTC decrementa tout e se questo scade mette il processo nello stato di pronto. Se qualcuno fa Signal sul semaforo mette Pronto il processo. Ovviamente il processo deve poter distinguere tra le due cause di risveglio. Signal (semaphore). Incrementa semaphore e se poi è > 0 mette nello stato di pronto il primo processo in attesa su quel semaforo. Il processo che esegue la Signal non rimane bloccato in attesa di quello che eseguirà la Wait sullo stesso semaforo. Per questo motivo la Signal può essere invocata anche all'interno di una ISR. I Sistemi Operativi Real-Time © Luca Massoletti

56 Primitive di comunicazione
 Le primitive di comunicazione si possono considerare come un'estensione delle primitive di sincronizzazione, a cui è però associato anche il trasporto di informazioni. PRODUTTORE - CONSUMATORE DI EVENTI Senza bufferizzazione. In questo caso è necessaria una sincronizzazione stretta e quindi la comunicazione è basata su rendez-vous. I Sistemi Operativi Real-Time © Luca Massoletti

57 Produttore – Consumatore di eventi
Con bufferizzazione di messaggi. Qui la sincronizzazione è lasca. I messaggi vengono accodati in liste FIFO. Send_Mess (message, queue). Accoda il messaggio message nella coda queue (detta spesso mailbox), senza attendere il consumatore. Se la coda è a lista non c'è pericolo di coda piena. Receive_Mess (queue, message [, tout]). Il processo riceve il primo messaggio nella coda queue, eventualmente attendendo che ne arrivi uno. E' spesso necessario prevedere una gestione con time-out. I Sistemi Operativi Real-Time © Luca Massoletti

58 Produttore – Consumatore di eventi
Con bufferizzazione di singoli caratteri. Si utilizzano spesso buffer circolari basati su array con opportuna gestione degli indici di produzione e di consumo. Put_Char (char, buffer [, tout]). Inserisce il carattere char nel buffer (circolare) se c'è posto, altrimenti attende che si liberi un posto, eventualmente con il tempo limite tout. Get_Char (buffer, char [, tout]). Attende, eventualmente con time-out, che ci sia un carattere nel buffer (circolare). I Sistemi Operativi Real-Time © Luca Massoletti

59 Scrittore – Lettori di stati
Se le informazioni sono di tipo stato, si deve instaurare il rapporto scrittore-lettori. Qui le informazioni sono basate su variabili globali. Ci deve essere una mutua esclusione tra le operazione dello scrittore e quelle dei lettori.  CLIENT - SERVER Client produce una richiesta Server consuma la richiesta Server esegue il servizio richiesto Server produce un esito Client consuma l'esito I Sistemi Operativi Real-Time © Luca Massoletti

60 Primitive di gestione delle risorse
Le primitive di gestione di risorse sono generalmente di livello superiore e basano le temporizzazioni, sincronizzazioni e comunicazioni necessarie al loro interno, sulle primitive di base già viste. I sistemi operativi adatti al supporto del tempo reale di solito supportano in modo adeguato almeno la gestione delle risorse "convenzionali" quali memoria ad allocazione dinamica (heap), memorie di massa, tastiera, linee di comunicazione, stampanti, ecc. Invece le risorse specifiche dell'applicazione vengono gestite dal programmatore applicativo usando le primitive precedentemente viste. I Sistemi Operativi Real-Time © Luca Massoletti

61 Gestione delle eccezioni
Questa gestione è molto importante per i sistemi di elaborazione in tempo reale. Infatti questi sistemi devono mantenere una validità anche in presenza di errori, tentandone il recupero o almeno il confinamento, e comunque continuando le attività possibili (persistenza). Una tecnica spesso usata si basa su una collezione di gestori di eccezioni scritti dal programmatore applicativo, a cui il sistema operativo cede il controllo su invocazione di apposite primitive, in occasione di specifiche interruzioni sincrone (trap) o quando rilevi direttamente situazioni anomale. I Sistemi Operativi Real-Time © Luca Massoletti

62 Problemi Problemi: Il rilievo delle anomalie è di solito fatto dalle routine a più basso livello, mentre i provvedimenti vanno presi a livello alto. Occorrono meccanismi per attribuire ogni anomalia ad un ben preciso processo. Se le anomalie riguardano i calcoli in esecuzione, questo è il processo running. Se le anomalie sono sull'I/O, è il processo responsabile dell'attivazione delle operazioni fallite. I Sistemi Operativi Real-Time © Luca Massoletti

63 Problemi Per gestire le situazioni eccezionali, si sceglie tra:
Abort. L'attività fallita viene sospesa. Privilegia l'integrità. Retry. L'attività viene rieseguita dopo eventuali reinizializzazioni, modifiche di contesto, ecc. Ignore. Si procede dopo aver "rappezzato" (privilegia la persistenza). Spesso si desidera che i gestori da attivare dipendano dal contesto del momento in cui si verifica l'anomalia. Si può ad esempio avere una gestione annidata, in cui ogni processo è corredato di una pila di gestori di eccezioni, in cui a diversi livelli di annidamento delle procedure si inseriscono e si estraggono i gestori adatti. Il gestore di eccezione deve trovare il contesto corrispondente al processo e al livello di interventi che deve effettuare.   I Sistemi Operativi Real-Time © Luca Massoletti

64 Primitive Tipiche primitive per la gestione di eccezioni sono:
On_exception (exception, exc_handler). Un processo chiede al sistema operativo di creare l'aggancio tra exception e il relativo gestore exc_handler. Raise (exception). Invocata dalla routine che rileva l'anomalia exception. Uno dei pochi linguaggi che prevedono direttamente un certo numero di funzioni per la gestione delle eccezioni è Ada. I Sistemi Operativi Real-Time © Luca Massoletti

65 Decsrittore dinamico di processo
Per descrivere lo stato e il contesto di un processo si può usare una struttura dati di tipo record, spesso chiamata TCB (Task Control Block), associata ad ogni processo all'atto della sua creazione e che contiene le diverse informazioni che ne caratterizzano l'evoluzione. Le informazioni contenute in questa struttura dati sono: Stato. L'informazione di solito è più ricca di quella riportata nei soliti diagrammi degli stati. Ad esempio lo stato di attesa deve essere specializzato con l'indicazione di quale evento il processo attende, e se l'attesa è con time-out. Tempo da attendere. Indica il tempo di attesa rimanente (attese temporizzate o time-out) utilizzando magari granularità diverse nei diversi casi di attesa. I Sistemi Operativi Real-Time © Luca Massoletti

66 Descrittore dinamico di processo
Inizio stack. E' utile in sede di debug o per operazioni di verifica automatica che non si abbiano overflow della pila. Stack pointer. Ovviamente tale informazione non può essere salvata sullo stack, come avviene per gli altri registri della CPU. Risorse. Si possono avere puntatori alle risorse allocate al processo (o a loro descrittori) quando queste sono in quantità limitata, mentre nei casi più complessi possono essere previste delle liste, la cui testa è prevista in un apposito campo del TCB. Possibili risorse allocate sono : I Sistemi Operativi Real-Time © Luca Massoletti

67 Descrittore dinamico di processo: risorse allocate
Messaggi ricevuti. Code private. Aree di memoria. Vettori di interrupt. Regioni critiche impegnate. File in uso. Periferiche condivise. La descrizione delle risorse allocate serve per: Verificare i diritti di accesso alle risorse. Realizzare particolari protocolli di scheduling. Effettuare i necessari rilasci delle risorse in caso di sospensione dei processi. I Sistemi Operativi Real-Time © Luca Massoletti

68 Tempo di esecuzione Questo contatore serve per:
Valutare il tempo di CPU mediamente utilizzato dal processo, cioè la sua componente del coefficiente di utilizzazione. Gestire il time-slicing per i processi di background, che consiste nell'effettuare una preemption dei processi che rimangano oltre la porzione di tempo loro assegnata. Calcolare il tempo di esecuzione residuo, necessario per particolari politiche di scheduling, come quella di tipo minimum slack. I Sistemi Operativi Real-Time © Luca Massoletti

69 Priorità Tale informazione va inclusa nel TCB se la priorità è dinamica. I motivi per usare una priorità dinamica sono: I processi possono chiedere che la priorità venga modificata in base all'importanza o urgenza delle azioni che devono di volta in volta eseguire. Il sistema operativo cambia dinamicamente la priorità dei processi per realizzare particolari politiche di scheduling, ad esempio per limitare il fenomeno dell'inversione di priorità di cui si è parlato precedentemente. I Sistemi Operativi Real-Time © Luca Massoletti

70 Esempio di una possibile implementazione della tabella TCB.
I Sistemi Operativi Real-Time © Luca Massoletti