Che materia stai cercando?

Anteprima

ESTRATTO DOCUMENTO

Sistemi operativi

• Caratteristiche generali: protezione

– In relazione alla protezione è importante sicuramente fornire

meccanismi d'identificazione e di accesso controllato a diverse

porzioni del sistema

• Per garantire una migliore stabilità del sistema si è arrivati a

separare l'accesso al sistema ottenuto eventualmente dai processi

che compongono l'applicazione e quelli che sono parte del SO

• Due modalità di esecuzione dei processi

– Kernel

» Riservata generalmente ai soli processi del sistema operativo: non vi sono

limitazioni all'accesso alle risorse hw del sistema e alle strutture dati del SO

– Utente

» L'accesso alle risorse del sistema avviene tramite chiamate alle primitive di

sistema operativo, ovvero in modo controllato e regolamentato

Sistemi Embedded 2010/2011 12

Sistemi operativi

• Caratteristiche generali: struttura

– Circa l'architettura del sistema operativo, si è assistito negli anni

a una differenziazione ed evoluzione degli approcci

• Pochi anni fa, buona parte dei SO aveva un'architettura monolitica

– Un grosso kernel contenente la maggior parte delle funzionalità fra cui

lo scheduling, la gestione della memoria di massa (file system), le

funzioni di rete, i driver dei dispositivi, e così via

• Architetture più recenti (microkernel), assegnano invece al kernel

poche funzioni essenziali, tipicamente la gestione degli spazi

d'indirizzamento e della comunicazione fra processi e lo scheduling

– Gli altri servizi vengono forniti da processi, talvolta operanti in modalità

utente, che vengono trattati dal kernel come dei server

Sistemi Embedded 2010/2011 13

Sistemi operativi

• Caratteristiche generali: struttura

– Un'altra importante evoluzione dell'architettura dei sistemi

operativi riguarda la granularità alla quale viene visto il

parallelismo

• Il multithreading è una tecnica che prevede la suddivisione

dell'attività di un processo su in insieme di thread, ovvero di

processi più piccoli e leggeri, eseguibili simultaneamente

– Sotto tale ipotesi, il thread è l'unità vera e propria di allocazione del

lavoro, eseguito sequenzialmente e che può essere interrotto,

esattamente come per i processi

» In un sistema a thread il processo assume invece il ruolo di contenitore di

uno o più thread e delle loro relative risorse, come la memoria o i file aperti

e i dispositivi

Sistemi Embedded 2010/2011 14

Sistemi operativi

• Caratteristiche generali: struttura

– Il partizionamento di applicazioni complesse su molti thread,

consente di migliorare significativamente la modularità

dell'applicazione e della temporizzazione

• Ogni thread può evolvere in modo indipendente, poiché ha

associato il concetto di stato e di evoluzione in modo del tutto

analogo ai processi

– La principale differenza risiede nella condivisione delle risorse, che per

tutti i thread appartenenti a un determinato processo è nativa, mentre

per essere realizzata da parte di un insieme di processi richiede

l'intervento diretto del sistema operativo

» Tale elemento è il punto di forza principale dei thread, poiché riduce

fortemente l'overhead per la gestione della concorrenza a carico del

sistema operativo

Sistemi Embedded 2010/2011 15

Sistemi operativi

• Caratteristiche generali: struttura

– In commercio vi sono sistemi operativi in grado di gestire

direttamente l'allocazione della CPU ai thread che compongono

l'applicazione, oppure altri in cui la funzione di scheduling dei

thread è inserita all'interno del processo che li contiene

– In molti ambiti i termini thread e processo sono usati in modo

abbastanza indistinto per rappresentare le unità di esecuzione

parallela componenti un'applicazione

Sistemi Embedded 2010/2011 16

Sistemi operativi

Sincronizzazione e comunicazione

Sistemi Embedded 2010/2011 17

Sistemi operativi

• Sincronizzazione e comunicazione

– L'insieme dei processi (o thread) che sono

contemporaneamente attivi all'interno di un sistema compete

sicuramente per l'utilizzo delle risorse, ma può essere anche

essere organizzato in modo da cooperare per un fine comune

• Si pensi ad esempio all'organizzazione di un foglio elettronico

– Un processo che acquisice le informazioni da parte dell'utente

– Un secondo processo che gestisce ed elabora la struttura dati che

rappresenta il foglio elettronico (svolgendo i calcoli)

– L'ultimo processo che ha il controllo della visualizzazione grafica

» Questi tre processi, pur competendo per l'uso della CPU, hanno necessità

di comunicare, per esempio fra il processo d'interfaccia utente e quello che

svolge i calcoli, e di sincronizzare l'ordine con cui alcune attività vengono

svolte: si visualizzano le informazioni una volta calcolati i nuovi valori

Sistemi Embedded 2010/2011 18

Sistemi operativi

• Sincronizzazione e comunicazione

– L'esempio precedente mostra alcune delle tipiche problematiche

di IPC (Inter-process Communication and Synchronization)

legate al coordinamento di processi concorrenti per un fine

comune o per garantire un accesso controllato alle risorse

• All'interno dei SO sono state studiate e messe a disposizione

diverse tecniche per consentire ai processi di comunicare o

assicurare la mutua esclusione nell'accesso alle risorse

– Le soluzioni esistenti sono decisamente diversificate, e spesso molti

approcci per fornire funzionalità di comunicazione sono utilizzabili

anche per sincronizzare le attività

Sistemi Embedded 2010/2011 19

Sistemi operativi

• Sincronizzazione e comunicazione

– Comunicare significa essenzialmente condividere informazioni

• Il modo più semplice per fornire tale servizio ai processi consiste nel

rendere scrivibile e leggibile da tutti una certa zona di memoria

– Questa soluzione richiede che il sistema operativo sia in grado di

rimuovere in modo flessibile parte dell'isolamento fra le aree di

memoria dei vari processi

» Per garantire, come spesso è necessario, l'accesso in scrittura in mutua

esclusione ai vari processi o, in generale, per forzare una certa sequenza

nell'ordine in cui si accede ai dati, i sistemi operativi mettono a disposizione

opportuni meccanismi di sincronizzazione

Sistemi Embedded 2010/2011 20

Sistemi operativi

• Sincronizzazione e comunicazione

– Una soluzione molto diffusa consiste nell'utilizzo dei cosiddetti

semafori

• Un semaforo, nella sua versione più semplice, consiste di una

variabile booleana e di due primitive per bloccare o rilasciare il

semaforo

– Prima di eseguire le istruzioni che accedono alla zona di memoria

condivisa, si cerca di bloccare il semaforo per segnalare l’accesso alla

risorsa in comune

» Se un altro processo ha svolto la stessa azione in precedenza, allora il

processo che ha cercato di prendere il semaforo viene bloccato su una

coda di attesa

» In caso contrario il processo prosegue modificando la zona di memoria

condivisa e, al termine, rilascia il semaforo

– La gestione di tutte le primitive di creazione e impostazione del

semaforo è sotto il controllo del sistema operativo; in questo modo

viene garantito che solo un processo alla volta può accedere alla zona

di codice che modifica la zona di memoria condivisa

Sistemi Embedded 2010/2011 21

Sistemi operativi

• Sincronizzazione e comunicazione

– I semafori sono solo uno degli strumenti di IPC offerti dai SO

• Ricordiamo i monitor, un meccanismo decisamente più astratto per

ottenere un accesso controllato alle risorse rispetto ai semafori

– Tale soluzione prevede d'incapsulare i dati e le procedure per la loro

manipolazione, in modo da nascondere la natura dei dati e il codice per

modificarli

» L'accesso alle strutture dati incapsulate nel monitor viene garantito dal

sistema operativo in mutua esclusione fra i processi

• I processi a volte possono scambiarsi informazioni tramite messaggi

– In questo caso vengono fornite due primitive di spedizione e ricezione

» Si può avere un tipo di sincronizzazione detta rendez-vous

» Esistono anche altre soluzioni dove la spedizione è non bloccante, mentre

la ricezione è bloccante (mailbox)

– Il meccanismo di comunicazione basato su messaggi è utilizzabile

anche per sincronizzare delle attività

Sistemi Embedded 2010/2011 22

Sistemi operativi

• Sincronizzazione e comunicazione

– Sotto il profilo della programmazione concorrente, non esistono

significative differenze funzionali fra i vari approcci, a parte

l'ovvia attitudine all'utilizzo in un ambito di rete dei messaggi

• Si può dimostrare che semafori, monitor e messaggi hanno la

stessa potenza espressiva

• Le differenze sostanziali sono la leggibilità e strutturazione

dell'applicazione e l'efficienza d'esecuzione da parte del SO

– E’ abbastanza intuitivo pensare che quanto più il codice di

un'applicazione richiede l'attraversamento di una cascata di chiamate di

sistema operativo, tanto più i tempi di risposta e l'overhead di sistema

peggioreranno

» Da tale punto di vista la memoria condivisa, eventualmente protetta da

semafori, in genere è la soluzione più efficiente, sebbene la sua

programmazione non sia particolarmente strutturata

Sistemi Embedded 2010/2011 23

Gestione del processore

Sistemi Embedded 2010/2011 24

Gestione del processore

• Il sistema operativo ha lo scopo di consentire una

gestione standardizzata, efficiente e regolamentata delle

risorse da parte dei vari processi in cui un'applicazione

può essere scomposta

– Lo scheduling è una delle responsabilità del sistema operativo

che ha maggiore impatto sulle prestazioni, efficienza nell'uso

delle risorse e soprattutto tempi di risposta del software

• In questa parte discuteremo gli aspetti generali che attengono alla

gestione della CPU e alla sua attribuzione ai processi

Sistemi Embedded 2010/2011 25

Gestione del processore

• Criteri di scheduling

– I criteri guida nella scelta dell'algoritmo per l'allocazione della

CPU sono molteplici e condizionati dall'ambito applicativo

• La prima distinzione è fra criteri orientati all'utente o al sistema

– I primi tengono in considerazione come viene percepito il sistema

– Nei secondi l'obiettivo è raggiungere un alto grado di sfruttamento della

CPU

– La prevedibilità di un tempo di servizio è difficile da definire

esattamente

• Le variazioni del carico e l'interazione fra i processi rendono difficile

prevedere le attese e la frazione di CPU destinata ad un processo

– Come vedremo nel seguito, nei sistemi embedded con esigenze di

real-time spesso la prevedibilità sarà raggiunta sacrificando parte della

potenza di calcolo

Sistemi Embedded 2010/2011 26

Gestione del processore

• Criteri di scheduling

– Principali criteri di scheduling

• Orientati all'utente

– Tempo di risposta

– Tempo di turnaround

– Deadline

– Predicibilità

• Orientati al sistema

– Throughput

– Uso della CPU

– Fairness

– Priorità

– Bilanciamento

Sistemi Embedded 2010/2011 27

Gestione del processore

• Criteri di scheduling

– Altre decisioni significative sono legate al momento in cui

selezionare e avviare un altro processo all'esecuzione

• Vi sono due categorie principali di scheduling, a secondo che sia

possibile o meno per il sistema operativo forzare il rilascio della

CPU da parte di un processo

– Preemptive

» Il sistema operativo ha la facoltà di spostare il processo dallo stato di

esecuzione nello stato pronto. Il momento in cui viene presa questa

decisione può essere legata a diversi fattori, come la creazione di un nuovo

processo o l'arrivo di un interrupt

– Non preemptive

» In questo caso il processo continua la sua esecuzione finché non termina,

si blocca oppure richiede dei servizi di sistema operativo che comportano

l'esecuzione di un diverso processo

Sistemi Embedded 2010/2011 28

Gestione del processore

• Stati e transizioni

dei processi

Interrotto

Sistemi Embedded 2010/2011 29

Gestione del processore

• Criteri di scheduling

– Le strategie con preemption in genere sono più complicate da

implementare e comportano maggiore overhead per la CPU

• Ad ogni context switch, la CPU deve eseguire del codice di SO,

riducendo il tempo della CPU disponibile per le applicazioni

– Per raggiungere buoni livelli di efficienza è quindi necessaria anche la

cooperazione di meccanismi hardware integrati nei processori

– I benefici della preemption sono invece evidenti per sistemi

interattivi, poiché si evita che un processo detenga per troppo

tempo la CPU, aumentando i tempi di risposta

• Nella maggior parte dei sistemi interattivi si usa il time sharing

– Ad intervalli regolari (es. 100 ms), la CPU riceva un segnale

d'interruzione che attiva la preemption sul processo corrente, e la

selezione di uno nuovo per l'esecuzione

Sistemi Embedded 2010/2011 30

Gestione del processore

• Criteri di scheduling

– Principali algoritmi di scheduling

• FCFS o FIFO

• Round-robin

• Shortest process next

• Shortest remaining time

• Feedback

– Nei sistemi reali vengono utilizzate variazioni di tali algoritmi

• Normalmente si cerca di avere scheduler a breve termine molto

semplici, per contenere l'overhead, e scheduler a più lungo termine,

in grado di aggiustare e stabilizzare il comportamento del SO

Sistemi Embedded 2010/2011 31

Esigenze dei sistemi real-time

Sistemi Embedded 2010/2011 32

Esigenze dei sistemi real-time

• In molte applicazioni embedded con comportamento

reattivo, la velocità di risposta è un fattore cruciale per la

correttezza

– L'obiettivo è spesso quello di minimizzare il tempo di risposta

• In generale comporta un aggravio dei costi

– Si possono manifestare anche altri problemi, legati per esempio a

modificare l'allocazione delle risorse verso i processi che hanno criticità

sui tempi di risposta

» I rimanenti potrebbero essere soggetti a problemi di blocco o rallentamento

– Per tali motivi la determinazione della velocità da raggiungere

deve essere un frutto di un'attenta analisi di tipo

costo/prestazione che tenga conto delle reali necessità

Sistemi Embedded 2010/2011 33

Esigenze dei sistemi real-time

• Le problematiche di calcolo real-time stanno

guadagnando sempre maggiore attenzione sia a livello

commerciale che di ricerca

– Un sistema real-time ha un comportamento corretto in funzione

del valore della soluzione e del tempo in cui i risultati sono stati

prodotti

• Spesso, per potere essere effettivamente utili, i valori calcolati

devono essere disponibili entro prefissati tempi limite (deadline)

– Non sempre è la velocità di risposta il fattore caratterizzante

• Per esempio, l'intervallo di tempo fra due pressioni consecutive del

tasto del mouse produce risposte che sono semanticamente

diverse, ovvero le tempistiche, anche non stringenti, concorrono a

determinare la funzionalità del sistema

Sistemi Embedded 2010/2011 34

Esigenze dei sistemi real-time

• All'interno dei sistemi concorrenti il software è

organizzato in processi spesso chiamati task

– Task hard o soft real-time

• Uno dei principali problemi dei progettisti dei sistemi embedded è

identificare quale parte della computazione complessiva sia

effettivamente di un tipo o dell'altro

• In generale le elaborazioni dei task possono essere così

schematizzate

Sistemi Embedded 2010/2011 35

Esigenze dei sistemi real-time

• Rispetto a questo schema generale, può essere

identificato un certo insieme di varianti

– In alcuni casi può essere specificata non solo una deadline di

completamento, ma anche d'avvio, ovvero un tempo limite entro

il quale il task deve comunque iniziare a essere eseguito

– Il momento in cui il processo diventa pronto, può essere

periodico, aperiodico (ma comunque con un certo grado di

predicibilità), oppure totalmente impredicibile

– Analogamente anche in tempo di elaborazione può essere un

valore fisso, variabile o impredicibile

Sistemi Embedded 2010/2011 36

Esigenze dei sistemi real-time

• Inoltre, soprattutto in base al tipo di elaborazione

considerata, questa potrebbe essere interrompibile o

meno

– E’ difficile che l'intera elaborazione richieda di essere non

interrompibile

• La condizione più frequente è quella in cui il task è interrompibile a

esclusione di alcune regioni critiche

• Spesso è importante identificare delle priorità relative fra

i task per rappresentare quanto sia critico che un certo

task non rispetti le proprie deadline

– Può essere utile strutturare un task in modo da separare le

sezioni obbligatorie con deadline rigide, da quelle più opzionali

Sistemi Embedded 2010/2011 37

Esigenze dei sistemi real-time

• Infine il ventaglio delle risorse di cui ha bisogno un task

durante la sua esecuzione può essere più ampio rispetto

al solo tempo di CPU

– Questo causa competizioni nell'accesso alle risorse da parte dei

vari task

• In ogni caso, a livello di sistema operativo, il componente

che probabilmente è più importante sotto il profilo delle

prestazioni real-time è lo scheduler

Sistemi Embedded 2010/2011 38

Scheduling per il real-time

Sistemi Embedded 2010/2011 39

Scheduling per il real-time

• Le politiche di scheduling a breve termine sono quelle

che influiscono maggiormente sulle prestazioni real-time

dei SO

– Le applicazioni real-time possono essere soggette a vincoli sui

tempi di risposta che per applicazioni militari possono arrivare ai

microsecondi

• Il raggiungimento dei nuovi obiettivi richiede

coordinamento nel progetto dell'hardware e del software

di base del sistema

Sistemi Embedded 2010/2011 40

Scheduling per il real-time

Tempi di risposta

Sistemi Embedded 2010/2011 41

Scheduling per il real-time

• Tempi di risposta

– Nella maggioranza dei casi, i sistemi real-time non sono in grado

di gestire direttamente le deadline

• In genere si cerca di rendere rapido l'avvio all'esecuzione di un

processo quando la sua scadenza si approssima

– All'interno di un sistema, a seconda delle scelte di progetto e

della natura dell'applicazione, l'elaborazione è prelazionabile nel

caso in cui può essere interrotta

• Oltre all'estremo opposto, che non prevede la possibilità di

preemption, esistono anche casi intermedi

– Regioni critiche

– Consideriamo alcune possibili scelte progettuali a livello di

gestione dei processi del sistema operativo e i relativi tempi di

risposta a un evento

Sistemi Embedded 2010/2011 42

Scheduling per il real-time

• Tempi di risposta

– Round-robin (con preemption)

• Se il sistema riceve un evento legato a un processo di tipo real-time,

questo viene creato (se non già nello stato di attesa) e accodato alla

lista circolare dei processi in attesa

• Il tempo che intercorre fra l'evento e l'avvio all'esecuzione del

processo corrispondente potrebbe richiedere l'esecuzione di tanti

quanti di tempo, quanti sono i processi che lo precedono nella coda

• Questa soluzione porta a ritardi nei tempi di risposta normalmente

inaccettabili per sistemi real-time, sebbene la sua realizzazione sia

decisamente semplice

Sistemi Embedded 2010/2011 43

Scheduling per il real-time

• Tempi di risposta

– Priorità (senza preemption)

• In questo caso si può associare una priorità elevata al processo con

esigenze di tempo reale

• La sua esecuzione dall'arrivo dell'evento dipende, in assenza di

preemption, dal ritardo con cui il processo già in esecuzione al

momento in cui l'evento si verifica, termina o si blocca

• Infatti, con una opportuna scelta delle priorità, il processo real-time

sarebbe il primo fra quelli pronti

• Tale scelta potrebbe comunque portare a ritardi persino di secondi:

se un task lento a bassa priorità fosse in esecuzione quando si

verifica un evento critico anche questa soluzione sarebbe

inaccettabile

Sistemi Embedded 2010/2011 44

Scheduling per il real-time

• Tempi di risposta

– Priorità con punti di preemption

• Questa soluzione è maggiormente risolutiva

• Si ha ancora uno scheduler con priorità, dove comunque a intervalli

regolari e ben definiti esiste la possibilità di fare preemption sul

processo in esecuzione, se ve ne sono altri in attesa con priorità

maggiore

– Tale eventualità potrebbe accadere anche ai processi che sono parte

del kernel del sistema operativo

• I ritardi in questo caso potrebbero scendere ad alcuni millisecondi,

valore accettabile in molte applicazioni, real-time, non spinte

Sistemi Embedded 2010/2011 45

Scheduling per il real-time

• Tempi di risposta

– Preemption immediata

• In questo caso il sistema risponde in modo estremo, interrompendo

il processo corrente e avviando all'esecuzione il processo real-time,

eventualmente attendendo che il sistema operativo esca da una

possibile regione critica

• Il ritardo è essenzialmente quello del cambio di contesto, che può

scendere sino sotto i 100~microS

Sistemi Embedded 2010/2011 46

Scheduling per il real-time

• Tempi di risposta

– Gli esempi mostrati evidenziano come la possibilità di effettuare

la preemption sia uno strumento cruciale per ottenere bassi

ritardi nelle risposte del sistema

• I kernel senza preemption non consentono l'interruzione di un

processo eseguito in modalità kernel

– Tali processi proseguiranno quindi la loro elaborazione finché non sia

abbandonata tale modalità o cedano volontariamente il controllo

• Nel caso in cui sia possibile effettuare preemption nei confronti di

processi kernel, si ottengono migliori tempi di risposta al prezzo di

una progettazione del kernel decisamente complessa

– Per tale motivo molti sistemi operativi per applicazioni generali non

prevedono tale possibilità

Sistemi Embedded 2010/2011 47

Scheduling per il real-time

• Tempi di risposta

– Nel caso in cui si debba invece operare in contesti hard real-

time, è normalmente inevitabile adottare kernel con preemption

• Un approccio spesso adottato consiste nell'inserire dei punti di

preemption all'interno delle chiamate di sistema operativo che

hanno lunghi tempi di esecuzione, in sezioni del codice sicure e

stabili

– Dove le strutture dati del kernel non stanno subendo modifiche

• In tali punti il SO verifica se esiste un processo ad alta priorità che

può essere mandato in esecuzione e, in tale caso, procede al

cambio di contesto

• Si ritorna quindi alla chiamata di sistema interrotta nel punto di

preemption quando il processo a elevata priorità è terminato

Sistemi Embedded 2010/2011 48

Scheduling per il real-time

• Tempi di risposta

– Una soluzione alternativa per realizzare un kernel con diritto di

preemption consiste nel proteggere le modifiche alle strutture

dati del kernel mediante i tipici meccanismi di sincronizzazione

• Es. Semafori

– In tal modo il kernel può essere interrotto praticamente in ogni

momento, poiché i dati del kernel in corso di aggiornamento,

data la protezione, non possono comunque essere modificati da

altri processi

• Ovviamente tale soluzione porta a un codice delle chiamate di

sistema meno snello, poiché in ogni momento deve essere garantita

la correttezza delle strutture dati in caso d'interruzione

– Aiuto: kernel rientrante

Sistemi Embedded 2010/2011 49

Scheduling per il real-time

• Tempi di risposta

– Un codice è detto rientrante se è progettato in modo che una

singola copia del codice in memoria possa essere condivisa ed

eseguita contemporaneamente da più processi

• Affinché una routine o comunque una parte di codice sia rientrante

deve soddisfare questi requisiti

– Nessuna porzione del codice possa essere alterata durante

l'esecuzione

– Il codice non deve richiamare nessuna routine che non sia a sua volta

rientrante

– Il codice deve usare solo variabili temporanee allocate sullo stack

» Il codice non deve modificare né variabili globali né aree di memoria

condivisa né impiegare variabili locali statiche

• Se una data porzione di codice non rispetta queste regole, non è

possibile farla eseguire da più processi contemporaneamente senza

regolarne l'accesso tramite semafori o sezioni critiche

Sistemi Embedded 2010/2011 50

Scheduling per il real-time

• Tempi di risposta

– Una volta compreso il panorama delle scelte circa il

funzionamento dei kernel, e come questi influenzino la

complessità e i tempi di risposta del SO, si può focalizzare

l'attenzione sul sistema embedded nel quale è inserito

• Come detto più volte, la reattività agli eventi è una delle

caratteristiche salienti di un sistema embedded

– Un fattore cruciale è il tempo di reazione, ovvero il tempo che

intercorre fra il manifestarsi dell'evento e l'esecuzione del codice

che lo deve gestire

• A partire dall'evento esterno, che si traduce normalmente in

un'interruzione verso il processore, si hanno diversi ritardi prima che

sia eseguito effettivamente il processo real-time

Sistemi Embedded 2010/2011 51

Scheduling per il real-time

• Tempi di risposta

– Latenza nella risposta ad un evento

Sistemi Embedded 2010/2011 52

Scheduling per il real-time

• Tempi di risposta

– Il ritardo che si verifica nel caso di una interruzione dipende dal

tempo trascorso dalla notifica del segnale alla CPU, l'avvio e

l'esecuzione della routine per la sua gestione (ISR)

• In tale frangente si deve terminare l'istruzione corrente,

comprendere di quale interruzione si tratti, salvare lo stato del

processo in esecuzione e solo allora eseguire il codice della ISR

– Il tempo necessario all'avvio della ISR, non la sua esecuzione, è

la latenza relativa all'interruzione ed è cruciale che sia

minimizzato

Sistemi Embedded 2010/2011 53

Scheduling per il real-time

• Tempi di risposta

– Per tale motivo si deve cercare di contenere il più possibile

l'intervallo di tempo in cui le interruzioni sono disabilitate

• Come accade durante l'aggiornamento delle strutture dati del SO

– Ovviamente tale obiettivo incrementa la complessità nel progetto delle

funzioni di sistema operativo, poiché è necessario identificare e gestire

con precisione le parti di codice che possono essere interrotte

– La maggior parte dei SO-RT riduce i tempi in cui le interruzioni

sono inibite, ma per applicazioni hard real-time spesso è

necessario anche garantire i tempi massimi di risposta alle

interruzioni, per assicurare un comportamento deterministico

Sistemi Embedded 2010/2011 54

Scheduling per il real-time

• Tempi di risposta

– Con riferimento sempre alla figura precedente, l'altra

componente della catena dei ritardi è la latenza relativa al

dispatch

• Il tempo necessario per bloccare un processo e avviarne un altro

– La tecnica più comunemente utilizzata per ridurre la latenza di

dispatch consiste nell'adottare kernel con diritto di preemption

• Nella fase detta di conflitto, infatti, si devono prelazionare i processi

in esecuzione nel kernel e ottenere da parte dei processi a bassa

priorità le risorse necessarie per eseguire il processo RT

– Nei sistemi UNIX commerciali (Solaris), la latenza del dispatch con

preemption inibita supera i 100~ms, mentre con preemption abilitata

scende sotto il millisecondo

Sistemi Embedded 2010/2011 55

Scheduling per il real-time

• Tempi di risposta

– Un altro problema che può influenzare la latenza relativa al

dispatch è il fenomeno dell'inversione delle priorità

• Si supponga che un processo a elevata priorità debba leggere o

modificare i dati del kernel a cui accede un diverso processo che ha

priorità inferiore

– Se, come spesso accade, i dati del kernel sono protetti da un semaforo,

il processo a priorità più elevata di trova a dover attendere che i dati

siano rilasciati da un processo di priorità inferiore

• Quello che può accadere è che un processo con priorità intermedia

divenga attivo quando il processo a elevata priorità attende che

quello a bassa priorità rilasci il semaforo

– Tale processo potrebbe prelazionare quello a bassa priorità, ritardando

ulteriormente l'accesso alla risorsa da parte del processo a priorità più

elevata

Sistemi Embedded 2010/2011 56

Scheduling per il real-time

• Tempi di risposta

– Per ovviare a tale eventualità, si può ricorrere a un protocollo di

ereditarietà delle priorità

• Secondo tale approccio, i processi che posseggono risorse richieste

da un processo a priorità più elevata, ereditano temporaneamente

tale elevata priorità finché detengono la risorsa, in modo da evitare

l'inserimento di altri processi nella catena di attesa, dopodiché

ritornano alla priorità di partenza

– Tale meccanismo genera run-time overhead, in quanto lo scheduler

deve controllare le priorità di tutti i task che posseggono le risorse

richieste dal task RT

Sistemi Embedded 2010/2011 57

Scheduling per il real-time

• Tempi di risposta

– Una soluzione alternativa è chiamata priority ceiling

• La priorità viene assegnata direttamente alla risorsa ed è pari alla

massima priorità tra i task che possono accedere ai tale risorsa

• Ogni task che accede alla risorsa assume provvisoriamente la

priorità della risorsa stessa

– Spesso chiamata priorità istantanea

• Priority ceiling genera solo compile-time overhead

Sistemi Embedded 2010/2011 58


PAGINE

106

PESO

283.22 KB

AUTORE

Atreyu

PUBBLICATO

+1 anno fa


DESCRIZIONE DISPENSA

Vengono trattati i seguenti argomenti. Sistemi operativi: caratteristiche generali; sincronizzazione e comunicazione. Gestione del processore. Esigenze dei sistemi real-time. Scheduling per il real-time: tempi di risposta; RMS e EDF;
RTOS: Real Time Operating Systems; UNIX/Linux; Windows; VxWorks; Windows CE; Free software.


DETTAGLI
Corso di laurea: Corso di laurea magistrale in ingegneria delle telecomunicazioni
SSD:
Università: L'Aquila - Univaq
A.A.: 2011-2012

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher Atreyu di informazioni apprese con la frequenza delle lezioni di Sistemi embedded e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università L'Aquila - Univaq o del prof Pomante Luigi.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Sistemi embedded

Programmazione concorrente
Dispensa
Sistemi Embedded
Dispensa
SystemC
Dispensa
Real-time and embedded operating systems
Dispensa