politecnico di milano © luca massoletti corso di sistemi operativi i sistemi operativi real-time...

© Luca Massoletti© Luca Massoletti

Politecnico di MilanoPolitecnico di Milano

Corso di SISTEMI OPERATIVICorso di SISTEMI OPERATIVI

I Sistemi Operativi Real-TimeI Sistemi Operativi Real-TimeConcetti fondamentaliConcetti fondamentali

Professore:Professore:

William FornaciariWilliam Fornaciari

I Sistemi Operativi Real-TimeI Sistemi Operativi Real-Time © A/A 2000/2001 Luca Massoletti© A/A 2000/2001 Luca Massoletti- - 22 - -

SommarioSommario

Tempo reale e parallelismoModelli implementativi di parallelismo virtualeModello a processi sequenziali comunicantiScheduling temporale – PreemptionInterruzioni – Priorità – AnnidamentoCompetizione e cooperazionePrimitive

I Sistemi Operativi Real-TimeI Sistemi Operativi Real-Time © Luca Massoletti© Luca Massoletti- - 33 - -

Tempo reale e parallelismoTempo 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


Tempo reale e parallelismo Tempo reale e parallelismo Lo sLo scopo temporalecopo 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.


Tempo reale e parallelismo Tempo reale e parallelismo OOverlappingverlapping

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.


Tempo reale e parallelismo Tempo reale e parallelismo ParallelismoParallelismo

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.


Tempo reale e parallelismo Tempo reale e parallelismo PreemptionPreemption

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.


Tempo reale e parallelismo Tempo reale e parallelismo Parallelismo fisicoParallelismo 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.


Tempo reale e parallelismo Tempo reale e parallelismo Parallelismo virtualeParallelismo 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 processoreTEi = tempo di esecuzione netto dell'azione i-esimaTAi = intervallo tra le attivazioni dell'azione i-esima


Tempo reale e parallelismoTempo reale e parallelismo Parallelismo mistoParallelismo 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.


Tempo reale e parallelismoTempo 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


Modelli implementativi di Modelli implementativi di parallelismo virtualeparallelismo 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.


Time-driven 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.


Time-drivenTime-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


Time-drivenTime-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.


Time driven: pregiTime 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.


Time driven: difettiTime 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.


Execution-driven multitasking.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".


Event-driven multitaskingEvent-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.


Considerazioni sulle tecniche Considerazioni sulle tecniche presentatepresentate

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.


Task e threadsTask 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.


Task e threadsTask 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.


Stati dei processiStati 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.


Stati dei processiStati 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.


Come gli eventi producono Come gli eventi producono transizioni di statotransizioni di stato

Le transizioni di stato possono essere causate

da:

Eventi interni. Eventi esterni. Eventi temporali.


DDiagramma stati-transizioni iagramma 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).



• 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.



• 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.



• 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.


Scheduling temporale – PreemptionScheduling 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:

1. In seguito all'invocazione di una primitiva da parte del processo in esecuzione.

2. 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.


Non-preemptive schedulingNon-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.


Preemptive schedulingPreemptive 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.


Preemptive schedulingPreemptive 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 piu diffusi algoritmi di scheduling I piu diffusi algoritmi di scheduling temporale: obiettivitemporale: 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.


Algoritmi di scheduling: Round Algoritmi di scheduling: Round RobinRobin

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.


Round Robin: pregi e difettiRound 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.


Algoritmi di scheduling: FIFOAlgoritmi 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.


FIFO: pregi e difettiFIFO: 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.


Algoritmi di scheduling: Fixed Algoritmi di scheduling: Fixed PriorityPriority

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.


Fixed Priority: pregi e difettiFixed Priority: pregi e difetti

Pregi: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).


Algoritmi di scheduling: Rate Algoritmi di scheduling: Rate monotonicmonotonic

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.


Algoritmi di scheduling:Algoritmi di scheduling: Earliest deadline. 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.


Algoritmi di scheduling: Algoritmi di scheduling: Minimum Minimum laxitylaxity

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.


Ricordiamo che un algoritmo è ottimo quando garantisce il rispetto di tutte le scadenze in tutte le situazioni in cui ciò è possibile (feasible).


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.


Interruzioni – Interruzioni – PrioritàPriorità - Annidamento - 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.


LivelliLivelli di annidamento 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à.


CompetizioneCompetizione e cooperazione 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.


Temporizzazione – Sincronizzazione Temporizzazione – Sincronizzazione – Mutua esclusione– 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.


Temporizzazione – Sincronizzazione Temporizzazione – Sincronizzazione – Mutua esclusione– Mutua esclusione

Queste tre funzioni possono essere realizzate in due modi:

1. Inglobate in un linguaggio di programmazione appositamente progettato per la concorrenza rendendole così in parte invisibili al programmatore.

2. Eseguite come primitive del sistema operativo che il programmatore invoca in modo esplicito. Questo è l'approccio più diffuso


PrimitivePrimitive

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.


Primitive generaliPrimitive 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.


Primitive di temporizzazionePrimitive 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.


Procedure di sincronizzazioneProcedure 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.


Primitive di comunicazionePrimitive 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.


Produttore – Consumatore di eventiProduttore – 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.


Produttore – Consumatore di eventiProduttore – 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).


Scrittore – Lettori di statiScrittore – 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


Primitive di gestione delle risorsePrimitive 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.


Gestione delle eccezioniGestione 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.


ProblemiProblemi

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.


ProblemiProblemi

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.


PrimitivePrimitive

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.


Decsrittore dinamico di processoDecsrittore 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.


Descrittore dinamico di processoDescrittore 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 :


Descrittore dinamico di processo:Descrittore dinamico di processo: risorse allocate 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.


Tempo di esecuzioneTempo 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.


PPrioritàriorità

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.


Esempio di una possibile implementazione della tabella TCB.

politecnico di milano © luca massoletti corso di sistemi operativi i sistemi operativi real-time...

Documents