TDi < TEi + TEj

∑ TEi < TDj.

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:

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:

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

La realizzabilità fisica con un solo processore impone che sia U < 1, che è condizione necessaria, ma non sufficiente, perché possano essere rispettati tutti i vincoli temporali.

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.

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

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.

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.

 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

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

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

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

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

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.

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.

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.

 Le transizioni di stato possono essere causate da:

• Eventi interni.
• Eventi esterni.
• Eventi temporali.

Questo è un tipico 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).

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.

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.

Distinguiamo tra preemptive scheduling e 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.

E' la soluzione comunemente adottata. Ogni volta che assume il controllo, il sistema operativo ha l'occasione di individuare 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.

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.

 1.4.3 I PIU' DIFFUSI ALGORITMI DI SCHEDULING TEMPORALE

Gli obiettivi dello scheduling sono diversi:

• Semplicità dello scheduler.
• Massimizzazione del throughput del sistema.
• Massimizzazione della predicibilità temporale.
• Minimizzazione del rischio di anomalie gravi.

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.

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.

FIFO. Quando i processi diventano pronti sono collocati in fondo ad una coda FIFO. Viene estratto per l'attivazione il primo processo nella coda.

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.

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.

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

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.

Earliest deadline. Qui 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.

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.

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

Nella pagina seguente viene illustrato un esempio di scheduling a priorita in cui lo stato della coda cambia a seguito dell'entrata in attesa di un processo.

Figura 1.1. Esempio di scheduling basato sulle priorità: si vede prima la condizione iniziale della coda e poi lo stato della coda dopo che il processo A è entrato nello stato di attesa.

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.

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

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

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

 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.

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.

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.

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.

E' importante disporre della variante con time-out per tutte le primitive bloccanti.

A volte è utile che il processo che riceve l'evento prima dello scadere del time-out possa conoscere il tempo rimanente, da adottare come scadenza per la successiva richiesta di altri eventi. In questo modo si può imporre un intervallo di tempo globalmente concesso all'acquisizione di una sequenza di eventi.

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.

 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.
• Con bufferizzazione di messaggi. Qui la sincronizzazione è lasca. I messaggi vengono accodati in liste FIFO.

• Con bufferizzazione di singoli caratteri. Si utilizzano spesso buffer circolari basati su array con opportuna gestione degli indici di produzione e di consumo.

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

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.

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.

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

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.

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 tipicamente:

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

• Messaggi ricevuti.
• Code private.
• Aree di memoria.
• Vettori di interrupt.
• Regioni critiche impegnate.
• File in uso.
• Periferiche condivise.

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

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

Figura 1.2. Esempio di una possibile implementazione della tabella TCB.

Torna alla pagina principale.

Prosegui al capitolo 2.