OS | Alessandro Torcinovich

1 Introduzione

Tue, 04 Mar 2025 00:00:00 +0000

In questa lezione forniremo una panoramica generale delle componenti di un sistema di elaborazione, di un calcolatore e di un sistema operativo. Verranno toccati molti argomenti e introdotti molti concetti, a cui dedicheremo approfondimenti nelle lezioni successive.

1.1 - Sistema di elaborazione

Un sistema di elaborazione o sistema elaborativo (s.e.) ruota attorno quattro concetti fondamentali:

hardware: l’insieme delle componenti fisiche con cui il s.e. è assemblato. Sono inclusi, tra gli altri:
- La Central Processing Unit (CPU) che esegue istruzioni a essa assegnate e produce dati.
- La memoria che memorizza dati per utilizzo successivo.
- I dispositivi Input/Output (I/O) che permettono l’interazione tra il mondo del computer e quello esterno (p.e. il mouse, la tastiera, il monitor, lo scanner, la stampante, etc.).
programmi applicativi: strutture logiche ad alto livello che svolgono dei servizi per l’utente (p.e. editor di testo, fogli di calcolo, compilatori, browser web, etc.).
utente: l’entità umana che interagisce con il s.e. attraverso i dispositivi I/O.
sistema operativo (s.o.): l’insieme delle componenti logiche che controlla l’utilizzo dell’hardware e dei programmi applicativi. Il s.o. può essere visto come l’insieme di regole necessarie al corretto funzionamento del s.e.

Hardware, sistema operativo e programmi applicativi saranno indicati con il nome calcolatore/elaboratore, anche se esistono diverse definizioni.

In sintesi:

L’utente agisce sul s.e. tramite i programmi applicativi che offrono servizi all’utente.
I programmi applicativi svolgono i servizi richiesti e sono regolati dal s.o.
Il s.o. si occupa di gestire i programmi applicativi e il loro accesso all’hardware.
l’hardware elabora i dati necessari ai programmi applicativi.

1.2 - I sistemi operativi

L’implementazione di un sistema operativo dipende dallo scopo del calcolatore per cui è stato progettato. Per esempio:

I Personal Computer (PC) si concentrano sulla facilità d’utilizzo da parte dell’utente, con qualche attenzione prestazioni ma nessuna all’utilizzo delle risorse.
I calcolatori integrati (embedded) hanno una scarsa facilità d’uso e forniscono meno servizi rispetto a un PC. Esempi di calcolatori integrati sono i sistemi che troviamo negli elettrodomestici (p.e. forno microonde o autoradio).

Non c’è accordo sulle componenti logiche che fanno parte di un s.o.

Un s.o. comprende senz’altro il kernel, l’unico programma che funziona sempre nel calcolatore.
Possiamo includere anche i programmi di sistema utili al funzionamento del calcolatore ma che non fanno parte del kernel.
Quando si parla di s.o. si pensa comunemente a tutto il software incluso alla sua vendita, compresi i programmi applicativi predefiniti dal venditore, che non regolano il s.e.

1.3 - Panoramica generale del calcolatore

Un calcolatore è composto da una CPU, e vari dispositivi (p.e. unità disco, dispositivi audio, unità video, etc.). La comunicazione con la memoria avviene attraverso bus di sistema che permette lo scambio di dati. Ciascun dispositivo è associato a un controllore di dispositivo con una propria memoria interna (il buffer) e un insieme di registri specializzati. Il controllore si occupa della comunicazione tra la memoria e il dispositivo. La componente logica che funge da interfaccia di comunicazione è chiamata driver del dispositivo.

1.3.1 - Sistema a interruzioni

La comunicazione avviene tramite il meccanismo a interruzioni. Riportiamo i vari passaggi di un’operazione di I/O:

Il driver scrive nei registri del controllore la richiesta (p.e. “leggi un carattere dalla tastiera”, “scrivi un carattere sul monitor”, etc.).
Il controllore legge i registri ed effettua l’operazione richiesta, trasferendo i dati dal dispositivo al buffer o viceversa. Infine, notifica il driver dell’avvenuta operazione.
Il driver passa il controllo ad altre parti del s.o. attraverso un segnale di interruzione alla CPU.
La CPU, che esegue istruzioni in sequenza, viene così “interrotta” e trasferisce l’esecuzione a una locazione fissa della memoria che contiene solitamente l’indirizzo iniziale della procedura di servizio dell’interruzione.
Una volta completata la procedura, la CPU riprende l’elaborazione precedentemente interrotta.

La mappatura dell’interruzione alla corretta procedura di servizio dev’essere eseguita efficientemente. Anziché scorrere tutta la lista, per trovare quella corretta si utilizza un vettore delle interruzioni contenente gli indirizzi di memoria (puntatori) delle procedure. Il vettore viene salvato negli indirizzi di memoria più bassi e il segnale di interruzione codifica l’indirizzo, così da permettere un accesso veloce. Quando i tipi di interruzioni sono molti, l’indirizzo punta a una lista di procedure che verrà scorsa per cercare la giusta procedura.

1.3.1.1 - Procedura di gestione dell’interruzione

La CPU dispone di una connessione chiamata linea di richiesta di interruzione (interrupt-request line) che viene controllata dopo l’esecuzione di ogni istruzione. Di sotto riportiamo una schematizzazione della procedura di gestione dell’interruzione:

La CPU controlla la linea di richiesta di interruzione.
Se viene rilevata una richiesta la CPU interrompe l’esecuzione del programma e legge il codice di interruzione e salta alla procedura corretta.
La procedura salva le informazioni di stato dell’operazione interrotta in CPU.
La procedura esegue l’elaborazione necessaria ed esegue un’istruzione di ritorno (return_from_interrupt) caricando l’indirizzo di ritorno nel contatore di programma (program counter) della CPU.

In questo modo, la CPU è in grado di reagire a eventi asincroni, cioè non prestabiliti durante l’esecuzione (p.e. I/O).

Esistono tuttavia casi in cui non vogliamo che questo accada, per esempio, quando la CPU sta eseguendo un’operazione critica. Per tale motivo la CPU possiede due linee di richiesta interruzione:

non mascherabile (nonmaskable interrupt): è riservata a errori irreversibili (p.e. nella memoria)
mascherabile (maskable interrupt): può essere disattivata dalla CPU a seconda delle necessità.

In aggiunta, a ogni interruzione viene assegnato un livello di priorità in maniera da dare precedenza quelle critiche, senza la necessità di mascherare quelle meno critiche.

Parlando di I/O, il meccanismo a interruzioni è ottimo per piccole moli di dati. Quando le operazioni di interruzione si intensificano, (p.e. grosse moli di dati), si genera un sovraccarico (overhead) della CPU con conseguente rallentamento dell’esecuzione. In questo caso, è possibile risolvere il problema con la tecnica di accesso diretto alla memoria (DMA), tramite il quale il controllore trasferisce un intero blocco di dati dal proprio buffer alla memoria, o viceversa, senza l’intervento della CPU.

Infine, alcuni sistemi hanno abbandonato la configurazione a bus per introdurre gli switch, con cui più dispositivi fisici possono interagire con varie parti del sistema concorrentemente, piuttosto che contendersi il bus condiviso.

1.4 - Struttura della memoria

Il calcolatore necessita di mantenere uno stato interno dell’esecuzione in maniera da poter gestire efficentemente l’elaborazione. Per questo motivo, è necessario dotarlo di memoria. Con questo termine ci riferiamo a varie tecnologie preposte al salvataggio di informazioni. Il calcolatore dispone di una gerarchia di memorie. Le più veloci sono le più costose da produrre e perciò anche le più piccole. In aggiunta, alcune memorie sono volatili, ovvero perdono il loro stato quando viene a mancare la corrente. Di seguito riportiamo una categorizzazione:

Memorie volatili: le indichiamo con il termine generico memoria. Troviamo:
- Registri: presenti all’interno della CPU, sono il tipo di memoria più veloce. La CPU accede solamente a questa memoria per l’esecuzione delle istruzioni.
- Cache: una memoria estremamente veloce e piccola che è in grado di salvare dati recenti frequentemente usati per l’utilizzo in CPU. Può essere considerata come un’estensione dei registri.
- Memoria ad accesso casuale (random access memory, RAM): il luogo in cui vengono caricati i programmi per la loro esecuzione. Calcolatori general-purpose come i PC utilizzano la RAM, solitamente realizzata con una tecnologia a semiconduttori chiamata memoria dinamica ad accesso casuale (dynamic random access memory, DRAM). Viene pensata come un vettore di byte associati a uno specifico indirizzo per il loro accesso. L’interazione con la CPU avviene attraverso l’operazione di load, dalla RAM al registro, e store, dal registro alla RAM.
Memorie non-volatili: le indichiamo con NVS (nonvolatile storage). Si dividono generalmente in due tipologie, meccanica ed elettrica, chiamata in seguito NVM. Troviamo:
- Memoria di sola lettura elettricamente cancellabile e programmabile (EEPROM): contiene il programma di avviamento (bootstrap) che avvia il sistema operativo. È più lenta della RAM.
- Memoria secondaria: contiene al suo interno i programmi eseguibili dal calcolatore e le informazioni elaborate da essi. Esistono vari tipi di memoria secondaria, come i dischi magnetici (hard-disk drive, HDD) o i dispositivi di memoria non volatile (NVM).
- Memoria terziaria: solitamente scollegabile dal calcolatore e portabile, per questo motivo la definiamo anche “esterna”. Esempi di memoria terziaria sono i CD-ROM, i blu-ray, i nastri magnetici, etc.

1.5 - Struttura del processore

Finora abbiamo parlato genericamente di CPU per indicare il componente principale preposto all’esecuzione di istruzioni macchina. È un termine comunemente utilizzato, ma in realtà il termine corretto è processore, ovvero l’hardware che ospita al suo interno una o più CPU per il calcolo.

I calcolatori possono essere categorizzati in:

sistema monoprocessore: un sistema con un solo processore contenente una sola CPU. In questo caso, il processore è solitamente coadiuvato da alcuni processori specializzati con scopi più limitati di quello principale.
sistemi multiprocessore: contenenti più processori con una singola CPU (single-core). Questi sistemi sono più moderni e più efficienti, tuttavia con N processori il tempo di esecuzione non aumenta esattamente di N volte, ma meno. Ciò è dovuto alla necessità di coordinare i core e alla contesa per risorse condivise. I sistemi più comuni usano la multielaborazione simmetrica (symmetric multiprocessing, SMP) in cui ogni processore può eseguire tutte le operazioni del sistema. Il vantaggio consiste nel poter eseguire molti processi contemporaneamente, ma può accadere che una CPU sia sovraccarica e l’altra vuota. Questo problema può essere risolto con la condivisione di alcune strutture dati tra i due processori.

Il termine multiprocessore indica anche i sistemi multicore, in cui più CPU (core) risiedono su un singolo processore (o più processori). La comunicazione è in questo caso più efficiente dal punto di vista della velocità e della potenza consumata, poiché è possibile effettivamente implementare una memoria cache condivisa dai core. Dal punto di vista logico, il s.o. si interfaccia come con un normale sistema multiprocessore.

Come detto, con l’aumentare delle CPU l’aumento di potenza computazionale diminuisce poiché il bus di sistema condiviso diventa un collo di bottiglia. Per ovviare al problema è stato proposto un approccio alternativo chiamato accesso non uniforme alla memoria (NUMA). Le CPU sono dotate di una propria memoria e comunicano tramite un interconnessione di sistema condivisa. Lo svantaggio è la latenza introdotta durante l’accesso di una CPU a un’altra memoria.

1.6 - Attività del sistema operativo

Il s.o. si occupa di orchestrare i componenti di un calcolatore precedentemente descritti. In particolare, all’accensione del computer, viene lanciato il programma bootstrap, che si occupa di caricare in memoria il kernel del s.o. A sua volta il kernel inizia ad offrire servizi. L’utente interagirà col s.o. tramite eventi I/O che generano interruzioni, come spiegato sopra.

1.6.1 - Multiprogrammazione e multitasking

In questa sezione presentiamo due principali tecniche di orchestrazione dei programmi da parte del s.o.

La multiprogrammazione consiste nel tenere in memoria centrale diversi processi. Il s.o. lancia un processo in base alla priorità data e nei momenti di interrupt, quando la CPU sarebbe inattiva, vengono invece eseguiti gli altri processi, massimizzando così l’utilizzo della CPU.

Il multitasking è un’estensione logica della multiprogrammazione. Una CPU multitasking è in grado di eseguire più lavori (task) intervallando le loro esecuzioni per garantire tempi di risposta rapida a ogni processo. Un metodo per ottenere tale rapidità è quello di adottare una memoria virtuale ovvero una sovrastruttura logica che astrae la memoria fisica ed emula una memoria potenzialmente più grande di quella centrale.

1.6.2 - Duplice modalità di funzionamento

Un s.o. dev’essere in grado di proteggersi da errori dovuti a esecuzioni di programmi errati, ma dev’essere anche in grado di prendere il controllo degli stessi per quando necessario.

Per tale motivo il s.o. è in grado di distinguere le sue routine da quelle dell’utente attraverso la dual mode, per la quale si utilizza un bit (mode bit) che segnala l’appartenenza di un processo a una modalità di sistema privilegiata (0) o a una modalità utente non privilegiata (1).

All’avvio del calcolatore la modalità sistema è attiva, poi il s.o. passa alla modalità utente, per l’esecuzione delle applicazioni utente. Ogni volta che un’applicazione fa una chiamata a sistema (p.e. con un’operazione I/O), questa viene gestita come un’interruzione software. Il s.o. passa alla modalità sistema e una volta eseguita la procedura si ritorna nuovamente alla modalità utente.

La dual mode permette di definire istruzioni privilegiate (p.e. passaggio alla modalità kernel, etc.) che possono essere eseguite solo in modalità sistema. Se un programma utente causa un errore (p.e. accede a una zona di memoria proibita), l’hardware genera un’eccezione seguendo una condotta analoga a quella di un’interruzione. Il programma viene quindi terminato in maniera anomala.

È possibile implementare diversi livelli di privilegio (p.e. Intel ne ha quattro, ARMv8 ne ha sette). Inoltre, le CPU che supportano la virtualizzazione hanno spesso una modalità distinta per la gestione della macchina virtuale.

1.6.3 - Timer

A volte può accadere che un programma entri in un loop infinito. Questo comportamento pericoloso monopolizzerebbe la CPU a scapito del s.o. che non può più riprendere il controllo. Per evitare ciò si può utilizzare un timer programmabile affinché invii un’interruzinoe a intervalli fissi o variabili.

Il timer è implementato come un contatore che decresce a ogni impulso e quando raggiunge lo 0, genera un’interruzione. Il s.o. riprende dunque il controllo e decide se concedere altro tempo o interrompere il programma.

1.6.4 - Gestione delle risorse

Riportiamo ora una panoramica sulle mansioni di gestione del s.o.

1.6.4.1 - Gestione dei processi

Un programma interagisce con il s.o. e l’utente solamente se è caricato in memoria e la CPU esegue le sue istruzioni. Nel momento in cui è in esecuzione, parliamo di processo. Esempi di programmi sono il compilatore, un elaboratore di testi, o l’invio dati a una stampante. Un processo può anche avvalersi dell’utilizzo di vari sottoprocessi, detti jobs, parallelizzando così l’esecuzione.

Ogni processo a singolo job (o thread singolo, single-threaded) possiede un contatore di programma che indica quale istruzione eseguire. L’esecuzione avviene in maniera sequenziale. Nel caso di più thread il processo possiede più contatori di programma.

Il s.o. è responsabile delle seguenti mansioni di gestione dei processi:

creazione e cancellazione dei processi utenti e di sistema
schedulazione di processi e thread sulle CPU
sospensione e ripristino dei processi
fornitura di meccanismi per la sincronizzazione dei processi
fornitura di meccansimi per la comunicazione tra processi

1.6.5 Gestione dei file

Il file è l’unità logica per l’organizzazione dell’informazione in un computer. Ogni programma è salvato in un file, ma un file può anche rappresentare una collezione di informazioni correlate, per esempio un documento di testo o un immagine. La struttura di un file può essere rigidamente codificata (p.e. file MP3) o più flessibile (p.e. file di testo). Il contenuto di un file può essere di tipo numerico, alfabetico o alfanumerico. I file possono essere raggruppati in una cartella (directory) e a sua volta le cartelle possono essere raggruppate in altre cartelle, formando una struttura ad albero.

Il s.o. è responsabile delle seguenti attività connesse alla gestione dei file:

creazione e cancellazione di file e directory
fornitura delle funzioni fondamentali per la gestione di file e directory
associazione dei file ai dispositivi di memoria secondaria
creazione di copie di riserva (backup) dei file su dispositivi di memoriazzazione non volatili

1.6.6 - Gestione della memoria

Per eseguire un programma, è necessario che questo sia associato a indirizzi assoluti e sia caricato nella memoria. Quando il programma termina, la parte di memoria a esso dedicata viene liberata. Per migliorare l’efficienza di questo sistema, è possibile mantenere più programmi contemporaneamente in memoria. La scelta della struttura della memoria dipende dal tipo di s.e.

Il s.o. è responsabile delle seguenti mansioni di gestione dei processi:

tenere traccia di quali parti di memoria sono attualmente usate e da chi
assegnare e revocare lo spazio di memoria secondo le necessità
decidere quali processi (o parti di essi) e dati debbano essere caricati in memoria centrale o trasferiti sulla memoria di massa

1.6.6.1 - Gestione della memoria di massa

Il calcolatore ha bisogno di una memoria secondaria non volatile per mantenere il suo stato anche quando è spento. La maggior parte dei s.e. utilizza nastri magnetici e NVM per la memorizzazione.

Il s.o. è responsabile delle seguenti attività connesse alla gestione della memoria di massa:

montare/smontare (mounting/unmounting) le unità di memoria
gestione dello spazio libero
scheduling del disco
partizionamento
protezione

In alcuni casi è utile avere a disposizione anche delle memorie terziare, ad esempio per avere un backup dei dati.

1.6.6.2 - Gestione della cache

La cache è un’unità di memoria che replica parte dello stato della memoria centrale. È pensata per fornire un accesso veloce ai dati da parte del calcolatore ed è più piccola della memoria centrale perché più costosa. Il s.o. si occupa solitamente dell’interazione tra cache e memoria centrale, mentre l’hardware di sistema dedicato si occupa dell’interazione tra cache e CPU. Un calcolatore può contenere più cache per aumentare l’efficienza nell’esecuzione delle istruzioni.

1.6.6.3 - Coerenza della memoria

Avendo a che fare con più unità di memoria diverse (registro, cache, memoria centrale, memoria secondaria), è importante mantenere lo stesso stato di un’applicazione in maniera da avere una coerenza tra i dati processati dalla CPU. Questo non rappresenta di per sé un problema nei sistemi single-threaded, ma richiede maggiore attenzione in quelli multitasking, dove, nel caso di memoria condivisa da più processi, è necessario garantire che ognuno di essi acceda alla copia più recentemente modificata dei dati. La situazione si complica ulteriormente nei sistemi multiprocessore, per i quali ciascuna CPU possiede anche una cache locale che va mantenuta aggiornata (e diventa ancora più complicata nei sistemi distribuiti, con più calcolatori).

Questa situazione di coerenza della cache si risolve solitamente a livello hardware, senza l’intervento diretto del s.o.

1.6.6 - Gestione dell’I/O

La varietà di dispositivi I/O che un calcolatore può ospitare richiede un’interfaccia di gestione per permettere un’interazione più semplice, gestita dal s.o. sottosistema di I/O, composto dalle seguenti parti:

un componente di gestione della memoria, buffer di I/O, cache e spooling
un’interfaccia generale per i driver di dispositivi
i driver dei dispositivi

1.7 - Sicurezza e protezione

Per garantire un corretto funzionamento del s.e. è importante che il s.o. implementi dei sistemi di protezione dei dati. Ad esempio in un sistema a più utenti, un utente deve avere la garanzia di poter decidere chi può accedere ai suoi file. Similmente, in un sistema a più processi, un processo non può scrivere in parti di memoria ad esso non allocate, previa autorizzazione del s.o. In questi casi è possibile prevedere degli identificativi (ID) dell’utente e del processo per decidere di quali privilegi dispongano.

In aggiunta a ciò, pur essendo dotato di protezione adeguata, un sistema può rimanere esposto agli accessi abusivi rischiando malfunzionamenti. Se ad esempio a un utente vengono trafugate le informazioni di autenticazione, un soggetto malevolo può essere in grado di modificare i suoi file, anche se la protezione dati è attiva. È compito della sicurezza non permettere che ciò accada, difendendo il s.e. da attacchi provenienti dall’interno o dall’esterno.

1.8 - Sistemi embedded real-time

Tra i vari s.e., i sistemi embedded attualmente costituiscono la tipologia predominante di calcolatore. La loro interfaccia utente è poco elaborata o addirittura assente e i loro compiti sono piuttosto specifici (p.e. monitoraggio ambienti, gestione di dispositivi meccanici, etc.). I sistemi embedded sono molto vari e possono essere implementati sia con sistemi general-purpose (di cui viene utilizzata solo una parte) sia con sistemi special-purpose.

In generale, i loro s.o. sono real-time ovvero hanno dei vincoli di tempo molto rigidi nell’esecuzione dei loro task, poiché vengono spesso utilizzati per processi critici (p.e. la produzione industriale) e se non riescono a completare in tempo le loro attività possono innescare una crisi. Ad esempio un braccio robotico dovrà necessariamente eseguire un’operazione di stop prima che vada a scontrarsi con l’automobile che era impegnato a costruire.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 1.

Introduzione

Sat, 02 Mar 2024 00:00:00 +0000

Sistema di elaborazione

Un sistema di elaborazione o sistema elaborativo (s.e.) ruota attorno quattro concetti fondamentali:

hardware: l’insieme delle componenti fisiche con cui il s.e. è assemblato. Sono inclusi, tra gli altri:
- La Central Processing Unit (CPU) che esegue istruzioni a essa assegnate e produce dati.
- La memoria che memorizza dati per utilizzo successivo.
- I dispositivi Input/Output (I/O) che permettono l’interazione tra il mondo del computer e quello esterno (p.e. il mouse, la tastiera, il monitor, lo scanner, la stampante, etc.).
programmi applicativi: strutture logiche ad alto livello che svolgono dei servizi per l’utente (p.e. editor di testo, fogli di calcolo, compilatori, browser web, etc.).
utente: l’entità umana che interagisce con il s.e. attraverso i dispositivi I/O.
sistema operativo (s.o.): l’insieme delle componenti logiche che controlla l’utilizzo dell’hardware e dei programmi applicativi. Il s.o. può essere visto come l’insieme di regole necessarie al corretto funzionamento del s.e.

Hardware, sistema operativo e programmi applicativi saranno indicati con il nome calcolatore/elaboratore, anche se esistono diverse definizioni.

In sintesi:

L’utente agisce sul s.e. tramite i programmi applicativi che offrono servizi all’utente.
I programmi applicativi svolgono i servizi richiesti e sono regolati dal s.o.
Il s.o. si occupa di gestire i programmi applicativi e il loro accesso all’hardware.
l’hardware elabora i dati necessari ai programmi applicativi.

I sistemi operativi

L’implementazione di un sistema operativo dipende dallo scopo del calcolatore per cui è stato progettato. Per esempio:

I Personal Computer (PC) si concentrano sulla facilità d’utilizzo da parte dell’utente, con qualche attenzione prestazioni ma nessuna all’utilizzo delle risorse.
I calcolatori integrati (embedded) hanno una scarsa facilità d’uso e forniscono meno servizi rispetto a un PC. Esempi di calcolatori integrati sono i sistemi che troviamo negli elettrodomestici (p.e. forno microonde o autoradio).

Non c’è accordo sulle componenti logiche che fanno parte di un s.o.

Un s.o. comprende senz’altro il kernel, l’unico programma che funziona sempre nel calcolatore.
Possiamo includere anche i programmi di sistema utili al funzionamento del calcolatore ma che non fanno parte del kernel.
Quando si parla di s.o. si pensa comunemente a tutto il software incluso alla sua vendita, compresi i programmi applicativi predefiniti dal venditore, che non regolano il s.e.

Panoramica generale del calcolatore

Sistema a interruzioni

La comunicazione avviene tramite il meccanismo a interruzioni. Riportiamo i vari passaggi di un’operazione di I/O:

Il driver scrive nei registri del controllore la richiesta (p.e. “leggi un carattere dalla tastiera”, “scrivi un carattere sul monitor”, etc.).
Il controllore legge i registri ed effettua l’operazione richiesta, trasferendo i dati dal dispositivo al buffer o viceversa. Infine, notifica il driver dell’avvenuta operazione.
Il driver passa il controllo ad altre parti del s.o. attraverso un segnale di interruzione alla CPU.
La CPU, che esegue istruzioni in sequenza, viene così “interrotta” e trasferisce l’esecuzione a una locazione fissa della memoria che contiene solitamente l’indirizzo iniziale della procedura di servizio dell’interruzione.
Una volta completata la procedura, la CPU riprende l’elaborazione precedentemente interrotta.

La mappatura dell’interruzione alla corretta procedura di servizio dev’essere eseguita efficientemente. Anziché scorrere tutta la lista trovare quella corretta, si utilizza un vettore delle interruzioni contenente gli indirizzi di memoria (puntatori) delle procedure. Il vettore viene salvato negli indirizzi di memoria più bassi e il segnale di interruzione codifica l’indirizzo, così da permettere un accesso veloce. Quando i tipi di interruzioni sono molti, l’indirizzo punta a una lista di procedure che verrà scorsa per cercare la giusta procedura.

Procedura di gestione dell’interruzione

La CPU controlla la linea di richiesta di interruzione.
Se viene rilevata una richiesta la CPU interrompe l’esecuzione e legge il codice di interruzione e salta alla procedura corretta.
La procedura salva le informazioni di stato dell’operazione interrotta in CPU.
La procedura esegue l’elaborazione necessaria ed esegue un’istruzione di ritorno (return_from_interrupt) caricando l’indirizzo di ritorno nel contatore di programma (program counter) della CPU.

In questo modo, la CPU è in grado di reagire a eventi asincroni, cioè non prestabiliti durante l’esecuzione (p.e. I/O).

Esistono tuttavia casi in cui non vogliamo che questo accada, per esempio, quando la CPU sta eseguendo un’operazione critica. Per tale motivo la CPU possiede due linee di richiesta interruzione:

non mascherabile (nonmaskable interrupt): è riservata a errori irreversibili (p.e. nella memoria)
mascherabile (maskable interrupt): può essere disattivata dalla CPU a seconda delle necessità.

A ogni interruzione viene assegnato un livello di priorità in maniera da dare precedenza quelle più critiche, senza la necessità di mascheramento.

Parlando di I/O, il meccanismo a interruzioni è ottimo per piccole moli di dati. Quando le operazioni di interruzione si intensificano, (p.e. grosse moli di dati), si genera un sovraccarico (overhead) della CPU con conseguente rallentamento dell’esecuzionie. In questo caso, è possibile risolvere il problema con la tecnica di accesso diretto alla memoria (DMA), tramite il quale il controllore trasferisce un intero blocco di dati dal proprio buffer alla memoria, o viceversa, senza l’intervento della CPU.

Struttura della memoria

Il calcolatore necessita di mantenere uno stato interno dell’esecuzione maniera da poter gestire efficentemente l’elaborazione. Per questo motivo, è necessario dotarlo di memoria. Con questo termine ci riferiamo a varie tecnologie preposte al salvataggio di informazioni. Il calcolatore dispone di una gerarchia di memorie. Le più veloci sono le più costose da produrre e perciò anche le più piccole. In aggiunta, alcune memorie sono volatili, ovvero perdono il loro stato quando viene a mancare la corrente. Di seguito riportiamo una categorizzazione:

Memorie volatili: le indichiamo con il termine generico memoria. Troviamo:
- Registri: presenti all’interno della CPU, sono il tipo di memoria più veloce. La CPU accede solamente a questa memoria per l’esecuzione delle istruzioni.
- Cache: una memoria estremamente veloce e piccola che è in grado di salvare dati recenti frequentemente usati per l’utilizzo in CPU. Può essere considerata come un’estensione dei registri.
- Memoria ad accesso casuale (random access memory, RAM): il luogo in cui vengono caricati i programmi per la loro esecuzione. Calcolatori general-purpose come i PC utilizzano la RAM, solitamente realizzata con una tecnologia a semiconduttori chiamata memoria dinamica ad accesso casuale (dynamic random access memory, DRAM). Viene pensata come un vettore di byte associati a uno specifico indirizzo per il loro accesso. L’interazione con la CPU avviene attraverso l’operazione di load, dalla RAM al registro, e store, dal registro alla RAM.
Memorie non-volatili: le indichiamo con NVS (nonvolatile storage). Si dividono generalmente in due tipologie, meccanica ed elettrica, chiamata in seguito NVM. Troviamo:
- Memoria di sola lettura elettricamente cancellabile e programmabile (EEPROM): contiene il programma di avviamento (bootstrap) che avvia il sistema operativo. È più lenta della RAM.
- Memoria secondaria: contiene al suo interno i programmi eseguibili dal calcolatore e le informazioni elaborate da essi. Esistono vari tipi di memoria secondaria, come i dischi magnetici (hard-disk drive, HDD) o i dispositivi di memoria non volatile (NVM).
- Memoria terziaria: solitamente scollegabile dal calcolatore e portabile, per questo motivo la definiamo anche “esterna”. Esempi di memoria terziaria sono i CD-ROM, i blu-ray, i nastri magnetici, etc.

Struttura del processore

I calcolatori possono essere categorizzati in:

sistema monoprocessore: un sistema con un solo processore contenente una sola CPU è chiamato sistema monoprocessore. In questo caso, il processore è solitamente coadiuvato da alcuni processori specializzati con scopi più limitati di quello principale.
sistemi multiprocessore: contenenti più processori con una singola CPU (single-core). Questi sistemi sono più moderni e più efficienti, tuttavia con N processori il tempo di esecuzione non aumenta esattamente di N volte, ma meno. Ciò è dovuto alla necessità di coordinare i core e alla contesa per risorse condivise. I sistemi più comuni usano la multielaborazione simmetrica (symmetric multiprocessing, SMP) in cui ogni processore può eseguire tutte le operazioni del sistema. Il vantaggio consiste nel poter eseguire molti processi contemporaneamente, ma può accadere che una CPU sia sovraccarica e l’altra vuota. Questo problema può essere risolto con la condivisione di alcune strutture dati tra i due processori.

Il termine multiprocessore indica anche i sistemi multicore, in cui più CPU (core) risiedono su un singolo processore (o più processori). La comunicazione è in questo caso più efficiente dal punto di vista della velocità e della potenza consumata, poiché è possibile effettivamente implementare una memoria cache condivisa dai core. Dal punto di vista logico, il s.o. si interfaccia come con un normale sistema multiprocessore.

Come detto, con l’aumentare delle CPU l’aumento di potenza computazionale diminuisce poiché il bus di sistema condiviso diventa un collo di bottiglia. Per ovviare al problema è stato proposto un approccio alternativo chiamato accesso non uniforme alla memoria (NUMA). Le CPU sono dotate di una propria memoria e vengono comunicano tramite un interconnessione di sistema condivisa. Lo svantaggio è la latenza introdotta durante l’accesso di una CPU a un’altra memoria.

Attività del sistema operativo

Multiprogrammazione e multitasking

In questa sezione presentiamo due principali tecniche di orchestrazione dei programmi da parte del s.o.

Duplice modalità di funzionamento

Un s.o. dev’essere in grado di proteggersi da errori dovuti a esecuzioni di programmi errati, ma dev’essere anche in grado di prendere il controllo degli stessi per quando necessario.

Per tale motivo il s.o. è in grado di distinguere le sue routine da quelle dell’utente attraverso la dual mode, per la quale si utilizza un bit che segnala l’appartenenza di un processo a una modalità di sistema privilegiata (0) o a una modalità utente non privilegiata (1).

All’avvio del calcolatore la modalità sistema è attiva, poi il s.o. passa alla modalità utente, per l’esecuzione delle applicazioni. Ogni volta che viene fatta una chiamata a sistema (p.e. con un’operazione I/O), questa viene gestita come un’interruzione software. Il s.o. passa alla modalità sistema e una volta eseguita la procedura si ritorna nuovamente alla modalità utente.

Timer

Il timer è implementato come un contatore che si decrementa a ogni impulso e quando raggiunge lo 0, genera un’interruzione. Il s.o. riprende dunque il controllo e decide se concedere altro tempo o interrompere il programma.

Gestione delle risorse

Riportiamo ora una panoramica sulle mansioni di gestione del s.o.

Gestione dei processi

Il s.o. è responsabile delle seguenti mansioni di gestione dei processi:

creazione e cancellazione dei processi utenti e di sistema
schedulazione di processi e thread sulle CPU
sospensione e ripristino dei processi
fornitura di meccanismi per la sincronizzazione dei processi
fornitura di meccansimi per la comunicazione tra processi

Gestione dei file

Il s.o. è responsabile delle seguenti attività connesse alla gestione dei file:

creazione e cancellazione di file e directory
fornitura delle funzioni fondamentali per la gestione di file e directory
associazione dei file ai dispositivi di memoria secondaria
creazione di copie di riserva (backup) dei file su dispositivi di memoriazzazione non volatili

Gestione della memoria

Il s.o. è responsabile delle seguenti mansioni di gestione dei processi:

tenere traccia di quali parti di memoria sono attualmente usate e da chi
assegnare e revocare lo spazio di memoria secondo le necessità
decidere quali processi (o parti di essi) e dati debbano essere caricati in memoria centrale o trasferiti sulla memoria di massa

Gestione della memoria di massa

Il calcolatore ha bisogno di una memoria secondaria non volatile per mantenere il suo stato anche quando è spento. La maggior parte dei s.e. utilizza nastri magnetici e NVM per la memorizzazione.

Il s.o. è responsabile delle seguenti attività connesse alla gestione della memoria di massa:

montare/smontare (mounting/unmounting) le unità di memoria
gestione dello spazio libero
scheduling del disco
partizionamento
protezione

In alcuni casi è utile avere a disposizione anche delle memorie terziare, ad esempio per avere un backup dei dati.

Gestione della cache

Coerenza della memoria

Avendo a che fare con più unità di memoria diverse (registro, cache, memoria centrale, memoria secondaria), è importante mantenere lo stesso stato di un’applicazione in maniera da avere una coerenza tra i dati processati dalla CPU. Questo non rappresenta di per sé un problema nei sistemi single-threaded, ma richiede maggiore attenzione in quelli multitasking, dove è necessario garantire che ogni processo acceda alla copia più recente di un dato. La situazione si complica con i sistemi multiprocessore, per i quali ciascuna CPU possiede anche una cache locale (e diventa ancora più difficile nei sistemi distribuiti, con più calcolatori).

Questa situazione di coerenza della cache si risolve solitamente a livello hardware, senza l’intervento diretto del s.o.

Gestione dell’I/O

un componente di gestione della memoria, buffer di I/O, cache e spooling
un’interfaccia generale per i driver di dispositivi
i driver dei dispositivi

Sicurezza e protezione

Per garantire un corretto funzionamento del s.e. è importante che il s.o. implementi dei sistemi di protezione dei dati. Ad esempio in un sistema a più utenti, un utente deve avere la garanzia di poter decidere chi può accedere ai suoi file. Similmente, in un sistema a più processi, un processo non può scrivere in parti di memoria ad esso non allocate, previa autorizzazione del s.o. In questi casi è possibile prevedere degli ID identificativi dell’utente e del processo per decidere di quali privilegi dispongano.

Sistemi embedded real-time

Tra i vari s.e. i sistemi embedded attualmente costituiscono la tipologia predominante di calcolatore. La loro interfaccia utente è poco elaborata o addirittura assente e i loro compiti sono piuttosto specifici (p.e. monitoraggio ambienti, gestione di dispositivi meccanici, etc.). I sistemi embedded sono molto vari e possono essere implementati sia con sistemi general-purpose (di cui viene utilizzata solo una parte) sia con sistemi special-purpose.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 1.

2 Strutture dei sistemi operativi

Thu, 06 Mar 2025 00:00:00 +0000

In questa lezione andremo a vedere le caratteristiche di design da tenere in considerazione quando si sviluppa un sistema operativo. Parleremo dei principali servizi che un sistema operativo deve fornire, delle chiamate a sistema con le quali è chiamato a operare e delle varie tipologie di architetture di un s.o.

2.1 Servizi di un sistema operativo

Nel capitolo precedente abbiamo fatto una panoramica generale sui calcolatori e i sistemi operativi. Ricapitoliamo i servizi principali che un s.o. deve fornire:

Interfaccia con l’utente (user interface, UI): è il metodo di interazione con il calcolatore. Tipicamente si utilizza un’interfaccia utente grafica (Graphical User Interface, GUI) con primitive grafice denominate “finestre”. Smartphone e tablet utilizzano interfacce touch con le quali lo schermo funge da dispositivo di input e output. Infine, è possibile anche utilizzare un’interfaccia a riga di comando (Command Line Interface, CLI) dalla grafica stilizzata, la cui interazione avviene con una tastiera.
Esecuzione di un programma
Operazioni di I/O
Gestione del file system
Comunicazioni tra processi
Rilevamento di errori
Allocazione delle risorse
Logging
Protezione e sicurezza

2.2 Interfaccia utente

L’interfaccia è l’architettura logica per comunicare con il s.o.

2.2.1 Interfaccia a riga di comando (CLI)

Una command line interface (CLI) ruota attorno al concetto di interprete dei comandi, un programma speciale che si avvia all’avvio di un job o al login dell’utente. Un s.o. può proporre diverse scelte chiamate shell (p.e. la Bourne-Again Shell, BASH, nei sistemi UNIX/Linux).

Il compito principale dell’interprete è di eseguire i comandi che vengono digitati dall’utente al suo interno. Esempi di comandi sono la creazione oppure la ricerca di un file. Il comando può fare riferimento a un programma nativo dell’interprete o a uno di sistema, esterno ad esso.

Esempio: rm file.txt rimuove il file chiamato file.txt. L’interprete cerca un file chiamato rm, lo carica in memoria e lo esegue con il parametro file.txt.

La CLI garantisce un’interazione a basso livello con il calcolatore.

2.2.2 Interfaccia grafica con l’utente

Una Graphical User Interface (GUI) fornisce una grafica più elaborata e intuitiva. Invece di digitare i comandi, gli utenti possono selezionare elementi visuali presenti sulla schermata, come ad esempio le icone di file. Un programma o una cartella verrà quindi rappresentato dalla propria icona con un nome sottostante.

La GUI garantisce più facilità d’uso ma meno flessibilità rispetto a una CLI.

2.2.2.1 Interfaccia touch screen

È una GUI che permette la trasmissione di input tattili. Molti dispositivi portatili odierni ne fanno uso.

2.3 Chiamate di sistema

Le chiamate di sistema (system call) sono routine invocate da un programma per chiedere al s.o. di fare qualcosa. Sono generalmente scritte in C/C++. L’esecuzione di un comando richiede solitamente più chiamate a sistema. Il comando cp in.txt out.txt, che copia il contenuto del file in.txt sul file out.txt. richiede varie chiamate a sistema tra cui una per aprire il file di input e una per creare il file di output.

2.3.1 Interfaccia per la programmazione di applicazioni (API)

Il comando cp precedentemente illustrato è composto da una serie di comandi che vengono raggruppati per evitare all’utente di dover specificare passo per passo tutte le chiamate a sistema. L’astrazione e il raggruppamento dei comandi è uno dei concetti base dello sviluppo di codice.

Per alleviare il carico cognitivo, dunque, gli sviluppatori predispongono una application programming interface API, contenente una serie di funzioni documentate a disposizione del programmatore, in maniera da schermarlo dai dettagli a basso livello del codice. Il termine interfaccia è qui utilizzato con un significato diverso da quello visto precedentemente. Un’API garantisce anche la portabilità verso altri sistemi che garantiscono il supporto all’API. Esempi di API sono l’API Windows, l’API POSIX (utilizzata nei sistemi UNIX, Linux e macOS).

Collegato all’API c’è l’ambiente di esecuzione al run-time (RTE, run-time environment). La suite completa di programmi necessaria per eseguire applicazioni scritte in un determinato linguaggio di programmazione, che include i compilatori o gli interpreti e altri software, come librerie e loader. L’RTE fornisce un’interfaccia alle chiamate di sistema (system call interface) che collega il linguaggio alle system call del s.o.

Le chiamate a funzione dell’API vengono intercettate dal RTE che invoca le relative chiamate a sistema e passa poi il risultato nuovamente all’API.

Talvolta, le chiamate a sistema richiedono dei parametri. Questi possono essere passati direttamente nei registri della CPU. Se però ce ne sono troppi è necessario memorizzarli in un blocco o tabella di memoria passando poi il suo indirizzo. Alternativamente, è possibile utilizzare uno stack in cui i parametri vengono inseriti (push) e poi successivamente prelevati (pop) dal s.o.

2.3.2 Categorie di chiamate a sistema

Le classifichiamo in sei categorie:

controllo dei processi
gestione dei file
gestione dei dispositivi/risorse
gestione delle informazioni
comunicazioni
protezione

Utilizziamo denominazioni generiche, poiché le chiamate hanno nomi specifici in base al s.o. utilizzato.

2.3.2.1 Controllo dei processi

Chiamate:

Notificare la normale terminazione di un processo (end())
Notificare la terminazione anomala di un processo (abort())
Salvare copia dello stato (memory dump, dump()) per debug
Generare messaggi d’errore su schermo

In caso di esecuzione anomala, il s.o. passa il controllo all’interprete dei comandi che continua a eseguire i comandi successivi. È compito dell’utente rispondere all’errore. È possibile stabilire un livello di errore ($0$ indica la terminazione normale).

Problema: a chi ritornare il controllo in caso p.e., di terminazione anomala o esecuzione parallela?

Caricamento (load()) ed esecuzione (execute()) di un altro processo.
Ispezione (get_process_attributes()) e impostazione (set_process_attributes()) degli attributi del processo (p.e. priorità, tempo max di esecuzione, etc.)
Impostazione di criteri di terminazione, p.e. timer (wait_time()) o attesa di un evento (wait_event()) che dev’essere segnalato (signal_event()).

Se due processi tentano di scrivere su una zona di memoria condivisa, c’è il rischio che venga rovinata l’integrità dei dati. Per ovviare al problema, un processo può bloccare il file prevenendo l’intervento di altri processi su di esso, acquisendo un lock. Il lock sarà poi rilasciato a operazione conclusa. Le chiamate a sistema relative sono

Acquisizione (acquire_lock()) e rilascio (release_lock()) del lock.

2.3.2.2 Gestione dei file

Chiamate:

Creare (create()) e cancellare (delete()) file
Aprire (open()), leggere (read()), scrivere (write()) e chiudere (close()) file
Spostare (move()), copiare (copy()) e incollare (paste()) file

2.3.2.3 Gestione dei dispositivi/risorse

Essenziali per l’interazione con l’utente e per la gestione dei processi. Parliamo genericamente di risorse fisiche (p.e. memoria centrale e secondaria) virtuali (p.e. i file) Chiamate:

Richiedere (request()) e rilasciare (release()) una risorsa
Leggere (read()) e scrivere (write()) una risorsa

2.3.2.4 Gestione delle informazioni

Chiamate:

Ottenere l’ora (time()) e la data (date())
Ottenere il numero di utenti collegati
Ottenere la versione del sistema operativo
Ottenere informazioni per il debug, come il dump (dump()).

2.3.2.5 Comunicazione tra processi

Esistono due modelli diffusi di comunicazione tra processi

Modello a scambio di messaggi: i processi utilizzano una casella di posta (mailbox) condivisa in cui si scambiano i messaggi. È necessaria l’identificazione dei processi attraverso il nome della macchina (host name) e l’identificatore del processo (Process ID, PID). Questo modello è utile per lo scambio di piccoli messaggi.

Le chiamate sono:

Accesso all’id dell’host (get_hostid()) del processo (get_processid())
Apertura (open_connection()) e chiusura della connessione (close_connection()). Vengono chiamate open()e close() conseguentemente.
Attesa (listening, wait_for_connection()) e accettazione della connessione (accept_connection()).
Lettura (read_message()) e scrittura (write_message()) dei messaggi

Modello a memoria condivisa: i processi usano chiamate di sistema per creare e accedere alle aree di memoria possedute da altri processi. Occorre coordinamento con gli altri processi e con il s.o., che di solito impedisce questa pratica. Questo modello è utile per ottenere maggiore efficienza nello scambio di messaggi.

Le chiamate sono:

Creare (shared_memory_create()) e accedere (shared_memory_attach()) ad aree di memoria possedute da altri processi

2.3.2.6 Protezione

Chiamate:

Impostare (set_permission()) e ottenere (get_permission()) i permessi di accesso alle risorse (p.e. file e dischi)
Permettere (allow_user()) o negare (deny_user()) l’accesso a una risorsa a un particolare utente.

2.4 Servizi di sistema

I servizi di sistema sono a un livello di astrazione superiore rispetto alle chiamate e offrono un ambiente più conveniente per lo sviluppo e l’esecuzione dei programmi. Possono essere semplici interfacce per le chiamate di sistema o architetture logiche più complesse. Li classifichiamo in:

Gestione dei file: per operazioni su file e directory
Informazioni di stato: data, monitoraggio memoria o prestazioni, etc.
Modifica dei file: per modificare il contenuto dei file
Ambienti di supporto alla programmazione: compilatori, assemblatori, debugger, interpreti, etc.
Caricamento ed esecuzione di programmi: per il caricamento in memoria dei programmi
Comunicazioni: per la comunicazione tra processi in locale e remoto
Servizi in background: anche noti come servizi, sottosistemi o demoni (daemon). Sono sempre attivi e attendono eventi per iniziare le loro routine (p.e. rilevare connessioni di rete, scheduling dei processi, etc.).

2.5 Programmi applicativi

A un livello maggiore troviamo i programmi applicativi che risolvono problemi comuni. Sono inclusi, ad esempio, i browser web, i processori di testo, fogli di calcolo, sistemi di basi di dati, videogiochi 🎮, etc.

2.6 Le differenze tra i sistemi operativi

In generale, un’applicazione può essere utilizzata solo per il sistema operativo per cui è stata progettata. Le cause principali sono:

Il s.o. ha un formato binario per le applicazioni con un header che dipende dal s.o. Certi metadati devono trovarsi esattamente nella posizione richiesta altrimenti il programma non può essere eseguito.
Le CPU hanno set di istruzioni differenti.
I diversi s.o. hanno chiamate di sistema differenti.

Una tecnica per mitigare questi problemi è accordarsi su uno standard da seguire. Similmente alle API è possibile definire un Application Binary Interface (ABI) per stabilire il modo in cui diversi componenti di un codice binario possano interfacciarsi su un determinato s.o. e architettura. Un’ABI specifica dettagli come la dimensione degli indirizzi, i metodi di passaggio dei parametri, l’organizzazione dello stack runtime, etc.

È comunque possibile creare delle applicazioni per più s.o. (cross-platform) in tre modi:

L’applicazione è scritta in un linguaggio interpretato (p.e. Python o Ruby). Le istruzioni vengono interpretate e poi tradotte nel set di istruzioni nativo. Questo comporta un overhead nelle performance.
L’applicazione è scritta in un linguaggio che supporta una macchina virtuale (p.e. Java). La macchina virtuale fa parte del RTE del linguaggio. Gli svantaggi sono simili a quelle dei linguaggi interpretati
Lo sviluppatore di un’applicazione può utilizzare un linguaggio specifico in cui il compilatore genera binari nel linguaggio del s.o. e della macchina (p.e. API Posix per il mantenimento della compatibilità del source code tra le varianti di s.o. UNIX-like). Questo richiede di portare l’applicazione su ciascun sistema in cui verrà eseguito con un conseguente overhead nella parte di sviluppo e debug.

2.7 Progettazione di un s.o.

Nello sviluppo di un s.o. bisogna avere in mente gli obiettivi degli utenti (utilità, facilità d’uso, velocità, etc.) e gli obiettivi del sistema (facilità di progettazione, facilità di manutenzione, flessibilità, affidabilità, etc.). La disciplina del software engineering si occupa anche di questi aspetti di progettazione.

2.7.1 Meccanismi e politiche

I meccanismi determinano come eseguire qualcosa. Un esempio è il timer di sistema che assicura la protezione della CPU. Un meccanismo mira a essere il più generico possibile per poterlo utilizzare con diverse politiche.
Le politiche stabiliscono cosa si debba fare. La decisione del tempo da impostare nel timer di sistema è una politica.

I sistemi operativi basati su microkernel separano politche e meccanismi permettendo solamente una serie di funzioni fondamentali da utilizzare come elementi di base per la progettazione.

2.8 Realizzazione di un s.o.

La realizzazione di un s.o. richiede la scelta di un linguaggio adatto. Originariamente il linguaggio utilizzato era l’assembly. Adesso si tende a utilizzare linguaggi ad alto livello come C/C++. I vantaggi sono portabilità e facilità di lettura del codice, al costo di una minore velocità d’esecuzione e una maggiore occupazione di spazio di memoria. Il compilatore si occuperà di ottimizzare l’assembly generato per garantire maggiore efficienza.

2.9 Struttura di un sistema operativo

Nel corso degli anni, sono state proposte diverse architetture per un s.o. Vediamone alcune:

2.9.1 Struttura monolitica

In questo caso, tutte le funzionalità del kernel vengono inserite in un singolo file binario statico che viene eseguito in un unico spazio d’indirizzamento. Esempi di kernel monolitico sono UNIX, diviso in kernel e programmi di sistema, e Linux che ha una struttura più modulare. Un s.o. monolitico ha il vantaggio della velocità di esecuzione ma è difficile da estendere. Per questo motivo viene chiamato anche sistema strettamente accoppiato (tightly coupled)

2.9.2 Struttura stratificata

In alternativa a un s.o. monolitico, possiamo progettare un sistema debolmente accoppiato (loosely coupled), suddiviso in componenti separate i cui cambiamenti agiscono solo su di esse. Questo permette uno sviluppo del s.o. più semplice. È possibile ad esempio stratificare i moduli: l’hardware corrisponderà allo strato più basso, mentre quello più alto sarà legato all’interfaccia con l’utente. Lo strato del s.o. è composto da strutture dati e routine utilizzabili da livelli più alti. L’architettura stratificata è stata utilizzata per le reti di computer (p.e. TCP/IP), ma molto poco per i s.o. per via della difficoltà di progettazione e degli overhead nella comunicazione tra strati.

2.9.3 Struttura a microkernel

Con la crescita in dimensioni dei sistemi monolitici, venne proposto una nuova architettura per il s.o. che si propose di eliminare tutte le componenti non essenziali dal kernel e di trasformarle in programmi utente o di sistema. Questo approccio, chiamato microkernel, garantisce facile estendibilità dei servizi, ma incorre in overhead dovuti alla comunicazione tra i servzi del s.o. Il microkernel è stato adottato per il s.o. Mach. Darwin, il kernel di macOS, ha anch’esso una struttura a microkernel ed è utilizzato assieme a Mach (parliamo quindi più propriamente di un’architettura a due microkernel).

2.9.4 Struttura a moduli

L’utilizzo di moduli del kernel caricabili dinamicamente è forse il miglior approccio disponibile per progettare un s.o. In questo caso, il kernel è costituito da componenti di base che vengono integrati dinamicamente con nuove funzionalità. Linux utilizza questo approccio con alcuni moduli del kernel caricabili.

2.9.5 Struttura ibrida

I s.o. odierni utilizzano solitamente più strutture tra quelle descritte prima. Linux e Solaris sono monolitici, ma anche modulari. Windows è in gran parte monolitico ma con alcuni aspetti progettati secondo l’architettura a microkernel e quella modulare.

2.10 Avvio di un sistema operativo

Il processo di avvio di un calcolatore è noto come boot e nella maggior parte dei casi funziona nel seguente modo:

Il programma di bootstrap o bootloader, si occupa di caricare il kernel del s.o.
Il kernel viene caricato in memoria ed eseguito
Il kernel inizializza l’hardware
Il file system principale (root file system) viene montato

Esistono vari programmi di avvio, di sotto ne riportiamo alcuni tra i più noti

multistage: All’accensione del calcolatore viene eseguito un bootloader situato nel firmware non volatile (BIOS). Solitamente questo programma carica un secondo booloader, il blocco di avvio (boot block), contenuto spesso in un unico blocco che carica a sua volta il resto del programma di bootstrap.
(Unified Extensible Firmware Interface) UEFI: è un gestore d’avvio unificato rispetto a BIOS, ed è quindi più veloce. Offre un supporto migliore per sistemi a 64 bit e dischi grandi.
GRUB: è un bootloader open-source per sistem Linux/UNIX, flessibile. Può caricare diversi kernel in base ai parametri specificati. All’avvio, GRUB crea un file system temporaneao in RAM, initramfs, che contiene driver e moduli da installare per l’inizializzazione. A seguire, Linux crea il processo iniziale di sistema, systemd, e avvia altri servizi, presentando poi il prompt di login.

Il processo di avvio per sistemi mobili è leggermente diverso e si basa spesso sulle scelte dei distributori.

Infine, il boot loader permette anche di avviare versioni più contenute del s.o., chiamate modalità di ripristino, o modalità a singolo utente, per la diagnostica.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 2.

Strutture dei sistemi operativi

Mon, 11 Mar 2024 00:00:00 +0000

Servizi di un sistema operativo

Nel capitolo precedente abbiamo fatto una panoramica generale sui calcolatori e i sistemi operativi. Ricapitoliamo i servizi principali che un s.o. deve fornire:

Interfaccia con l’utente (user interface, UI): è il metodo di interazione con il calcolatore. Tipicamente si utilizza un’interfaccia utente grafica (Graphical User Interface, GUI) con primitive grafice denominate “finestre”. Smartphone e tablet utilizzano interfacce touch con le quali lo schermo funge da dispositivo di input e output. Infine, è possibile anche utilizzare un’interfaccia a riga di comando (Command Line Interface, CLI) dalla grafica stilizzata, la cui interazione avviene con una tastiera.
Esecuzione di un programma
Operazioni di I/O
Gestione del file system
Comunicazioni tra processi
Rilevamento di errori
Allocazione delle risorse
Logging
Protezione e sicurezza

Interfaccia utente

L’interfaccia è l’architettura logica per comunicare con il s.o.

Interfaccia a riga di comando (CLI)

Esempio: rm file.txt rimuove il file chiamato file.txt. L’interprete cerca un file chiamato rm, lo carica in memoria e lo esegue con il parametro file.txt.

La CLI garantisce un’interazione a basso livello con il calcolatore.

Interfaccia grafica con l’utente

La GUI garantisce più facilità d’uso ma meno flessibilità rispetto a una CLI.

Interfaccia touch screen

È una GUI che permette la trasmissione di input tattili. Molti dispositivi portatili odierni ne fanno uso.

Chiamate di sistema

Le chiamate di sistema (system call) sono routine invocate da un programma per chiedere al s.o. di fare qualcosa. Sono generalmente scitte in C/C++. L’esecuzione di un comando richiede solitamente più chiamate a sistema. Il comando cp in.txt out.txt, che copia il contenuto del file in.txt sul file out.txt. richiede varie chiamate a sistema tra cui una per aprire il file di input e una per creare il file di output.

Interfaccia per la programmazione di applicazioni (API)

Le chiamate a funzione dell’API vengono intercettate dal RTE che invoca le relative chiamate a sistema e passa poi il risultato nuovamente all’API.

Categorie di chiamate a sistema

Le classifichiamo in sei categorie:

controllo dei processi
gestione dei file
gestione dei dispositivi/risorse
gestione delle informazioni
comunicazioni
protezione

Utilizziamo denominazioni generiche, poiché le chiamate hanno nomi specifici in base al s.o. utilizzato.

Controllo dei processi

Chiamate:

Notificare la normale terminazione di un processo (end())
Notificare la terminazione anomala di un processo (abort())
Salvare copia dello stato (memory dumpy, dump()) per debug
Generare messaggi d’errore su schermo

Problema: a chi ritornare il controllo in caso p.e., di terminazione anomala o esecuzione parallela?

Caricamento (load()) ed esecuzione (execute()) di un altro processo.
Ispezione (get_process_attributes()) e impostazione (set_process_attributes()) degli attributi del processo (p.e. priorità, tempo max di esecuzione, etc.)
Impostazione di criteri di terminazione, p.e. timer (wait_time()) o attesa di un evento (wait_event()) che dev’essere segnalato (signal_event()).

Acquisizione (acquire_lock()) e rilascio (release_lock()) del lock.

Gestione dei file

Chiamate:

Creare (create()) e cancellare (delete()) file
Aprire (open()), leggere (read()), scrivere (write()) e chiudere (close()) file
Spostare (move()), copiare (copy()) e incollare (paste()) file

Gestione dei dispositivi/risorse

Essenziali per l’interazione con l’utente e per la gestione dei processi. Parliamo genericamente di risorse fisiche (p.e. memoria centrale e secondaria) virtuali (p.e. i file) Chiamate:

Richiedere (request()) e rilasciare (release()) una risorsa
Leggere (read()) e scrivere (write()) una risorsa

Gestione delle informazioni

Chiamate:

Ottenere l’ora (time()) e la data (date())
Ottenere il numero di utenti collegati
Ottenere la versione del sistema operativo
Ottenere informazioni per il debug, come il dump (dump()).

Comunicazione tra processi

Esistono due modelli diffusi di comunicazione tra processi

Modello a scambio di messaggi: i processi utilizzano una casella di posta (mailbox) condivisa in cui si scambiano i messaggi. È necessaria l’identificazione dei processi attraverso il nome della macchina (host name) e l’identificatore del processo (Process ID, PID). Questo modello è utile per lo scambio di piccoli messaggi.

Le chiamate sono:

Accesso all’id dell’host (get_hostid()) del processo (get_processid())
Apertura (open_connection()) e chiusura della connessione (close_connection()). Vengono chiamate open()e close() conseguentemente.
Attesa (listening, wait_for_connection()) e accettazione della connessione (accept_connection()).
Lettura (read_message()) e scrittura (write_message()) dei messaggi

Modello a memoria condivisa: i processi usano chiamate di sistema per creare e accedere alle aree di memoria possedute da altri processi. Occorre coordinamento con gli altri processi e con il s.o., che di solito impedisce questa pratica. Questo modello è utile per ottenere maggiore efficienza nello scambio di messaggi.

Le chiamate sono:

Creare (shared_memory_create()) e accedere (shared_memory_attach()) ad aree di memoria possedute da altri processi

Protezione

Chiamate:

Impostare (set_permission()) e ottenere (get_permission()) i permessi di accesso alle risorse (p.e. file e dischi)
Permettere (allow_user()) o negare (deny_user()) l’accesso a una risorsa a un particolare utente.

Servizi di sistema

Gestione dei file: per operazioni su file e directory
Informazioni di stato: data, monitoraggio memoria o prestazioni, etc.
Modifica dei file: per modificare il contenuto dei file
Ambienti di supporto alla programmazione: compilatori, assemblatori, debugger, interpreti, etc.
Caricamento ed esecuzione di programmi: per il caricamento in memoria dei programmi
Comunicazioni: per la comunicazione tra processi in locale e remoto
Servizi in background: anche noti come servizi, sottosistemi o demoni (daemon). Sono sempre attivi e attendono eventi per iniziare le loro routine (p.e. rilevare connessioni di rete, scheduling dei processi, etc.).

Programmi applicativi

Le differenze tra i sistemi operativi

In generale, un’applicazione può essere utilizzata solo per il sistema operativo per cui è stata progettata. Le cause principali sono:

Il s.o. ha un formato binario per le applicazioni con un header che dipende dal s.o. Certi metadati devono trovarsi esattamente nella posizione richiesta altrimenti il programma non può essere eseguito.
Le CPU hanno set di istruzioni differenti.
I diversi s.o. hanno chiamate di sistema differenti. Una tecnica per mitigare questi problemi è accordarsi su uno standard da seguire. Similmente alle API è possibile definire un Application Binary Interface (ABI) per stabilire il modo in cui diversi componenti di un codice binario possano interfacciarsi su undeterminato s.o. e architettura. Un’ABI specifica dettagli come la dimensione degli indirizzi, i metodi di passaggio dei parametri, l’organizzazione dello stack runtime, etc.

È comunque possibile creare delle applicazioni per più s.o. (cross-platform) in tre modi:

L’applicazione è scritta in un linguaggio interpretato (p.e. Python o Ruby). Le istruzioni vengono interpretate e poi tradotte nel set di istruzioni nativo. Questo comporta un overhead nelle performance.
L’applicazione è scritta in un linguaggio che supporta una macchina virtuale (p.e. Java). La macchina virtuale fa parte del RTE del linguaggio. Gli svantaggi sono simili a quelle dei linguaggi interpretati
Lo sviluppatore di un’applicazione può utilizzare un linguaggio specifico in cui il compilatore genera binari nel linguaggio del s.o. e della macchina (p.e. API Posix per il mantenimento della compatibilità del source code tra le varianti di s.o. UNIX-like). Questo richiede di portare l’applicazione su ciascun sistema in cui verrà eseguito con un conseguente overhead nella parte di sviluppo e debug.

Progettazione di un s.o.

Meccanismi e politiche

I meccanismi determinano come eseguire qualcosa. Un esempio è il timer di sistema che assicura la protezaione della CPU. Un meccanismo mira a essere il più generico possibile per poterlo utilizzare con diverse politiche.
Le politiche stabiliscono cosa si debba fare. La decisione del tempo da impostare nel timer di sistema è una politica.

I sistemi operativi basati su microkernel separano politche e meccanismi permettendo solamente una serie di funzioni fondamentali da utilizzare come elementi di base per la progettazione.

Realizzazione di un s.o.

Struttura di un sistema operativo

Nel corso degli anni, sono state proposte diverse architetture per un s.o. Vediamone alcune:

Struttura monolitica

Struttura stratificata

Struttura a microkernel

Struttura a moduli

Struttura ibrida

Avvio di un sistema operativo

Il processo di avvio di un calcolatore è noto come boot e nella maggior parte dei casi funziona nel seguente modo:

Il programma di bootstrap o bootloader, si occupa di caricare il kernel del s.o.
Il kernel viene caricato in memoria ed eseguito
Il kernel inizializza l’hardware
Il file system principale (root file system) viene montato

Esistono vari programmi di avvio, di sotto ne riportiamo alcuni tra i più noti

multistage: All’accensione del calcolatore viene eseguito un bootloader situato nel firmware non volatile (BIOS). Solitamente questo programma carica un secondo booloader, il blocco di avvio (boot block), contenuto spesso in un unico blocco che carica a sua volta il resto del programma di bootstrap.
(Unified Extensible Firmware Interface) UEFI: è un gestore d’avvio unificato rispetto a BIOS, ed è quindi più veloce. Offre un supporto migliore per sistemi a 64 bit e dischi grandi.
GRUB: è un bootloader open-source per sistem Linux/UNIX, flessibile. Può caricare diversi kernel in base ai parametri specificati. All’avvio, GRUB crea un file system temporaneao in RAM, initramfs, che contiene driver e moduli da installare per l’inizializzazione. A seguire, Linux crea il processo iniziale di sistema, systemd, e avvia altri servizi, presentando poi il prompt di login.

Il processo di avvio per sistemi mobili è leggermente diverso e si basa spesso sulle scelte dei distributori.

Infine, il boot loader permette anche di avviare versioni più contenute del s.o., chiamate modalità di ripristino, o modalità a singolo utente, per la diagnostica.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 2.

3 Gestione dei processi

Tue, 11 Mar 2025 00:00:00 +0000

3.1 Concetto di processo

Un processo è un programma in esecuzione. Un nome alternativo è job, storicamente utilizzato quando i calcolatori elaboravano code di processi (job queues) in sequenza. In seguito, si affermarono sistemi time-shared che potevano eseguire più programmi utente (task) in contemporanea.

Lo stato di un processo è rappresentato dal suo contatore di programma (program counter) e i valori presenti nei registri del processore. La struttura di un processo è composta di:

Sezione di testo: il codice eseguibile
Sezione dati: le variabili globali
Heap: la memoria allocata dinamicamente in esecuzione
Stack: una locazione temporanea per i dati usati nell’invocazione di funzioni (p.e. parametri, indirizzi di ritorno, variabili locali)

Solo lo heap e lo stack occupano uno spazio variabile, mentre testo e dati rimangono fissi ai valori di inizializzazione del processo. In particolare, ogni volta che viene chiamata una funzione un record di attivazione contenente i parametri di funzione, le variabili locali e l’indirizzo di ritorno viene aggiunto allo stack, e una volta finita l’esecuzione della funzione, questo viene tolto. È importante far sì che le memorie di stack e heap non si sovrappongano.

Ripetiamo che un programma è un’entità passiva e un processo è un’entità attiva generata al momento del caricamento di un programma in memoria, p.e. facendo doppio-click su un file eseguibile in una GUI. Lo stesso programma può essere caricato più volte, generando più processi distinti. Un processo può anche generare altri processi, o essere un ambiente di esecuzione per altri processi (p.e. la virtual machine di Java).

3.1.1 Stati di processo

Un processo può trovarsi nei seguenti stati:

Nuovo: il processo è stato creato
Esecuzione (running): le istruzioni stanno venendo eseguite
Attesa (waiting): il processo sta attendendo un evento (p.e. I/O)
Pronto (ready): il processo è in attesa di essere assegnato a un processore
Terminato: il processo ha finito l’esecuzione

Questi nomi sono arbitrari e variano in base al s.o. Solamente un processo per core può essere in stato di esecuzione.

3.1.1.1 Blocco di controllo del processo

Ogni processo è rappresentato nel s.o. da un blocco di controllo (Process Control Block, PCB, o Task Control Block, TCB), contenente:

Stato del processo: uno degli stati sopra descritti
Contatore di programma: per tenere traccia dell’istruzione da eseguire
Registri della CPU: di molteplice natura (p.e. accumulatori, indici di registro, puntatori a stack, registri general purpose, informazioni sulle condizioni del codice, etc.). È informazione che va salvata in caso di interruzioni.
Informazioni sullo scheduling di CPU: per determinare quando il processo verrà eseguito (p.e. priorità del processo, puntatori a code di scheduling, etc.)
Informazioni sulla gestione della memoria: legate alle locazioni della memoria usate dal processo
Informazioni di accounting: p.e. il numero di CPU, i limiti di tempo, l’identificatore di job o processo, etc.
Informazioni sullo stato dell’I/O: p.e. la lista dei dispositivi I/O allocati al processo, la lista dei file in uso, etc.

3.1.1.2 Thread

Un processo può utilizzare più core del processore, separando i task e eseguendoli in thread diversi (p.e. un word processor può prendere in input caratteri e lanciare il controllo ortografico sul testo). In tal caso il processo ha un PCB per ogni thread.

3.2 Scheduling dei processi

Due concetti fondamentali ruotano attorno alla schedulazione dei processi:

Il multiprogramming permette alla CPU di essere sempre occupata con altri programmi, anche durante gli interrupt.
Il time sharing permette di eseguire tutti i processi per brevi lassi di tempo, alternandoli, in maniera che l’utente possa interagirci senza ritardi. Per determinare quale processo eseguire in un determinato istante, è necessario un process scheduler.

Per accomodare queste due scelte di design, è bene trattare i processi distinguendoli in due categorie:

I/O-bound per processi che fanno molte operazioni di I/O
CPU-bound per processi che utilizzano molto la CPU

Infine il numero di processi correntemente in memoria viene chiamato grado di multiprogramming.

3.2.1 Code di scheduling

Nel momento in cui un processo è pronto per essere eseguito, viene inserito nella coda ready, generalmente implementata come una linked list. Una volta selezionato per l’esecuzione (dispatched), il processo può presentare tre comportamenti:

In attesa di un evento (p.e. I/O). In questo caso viene messo nella coda wait e, quando pronto, di nuovo nella coda ready.
Creazione di un processo figlio (child process). Anche in questo caso il processo genitore (parent process) viene messo nella coda wait in attesa che il processo figlio finisca l’esecuzione, per poi venire rimesso nella coda ready.
Rimozione dal core di esecuzione, che può avvenire per via di un interrupt o all’esaurimento del tempo di esecuzione (time slice) allocato al processo. In questo caso il processo viene spostato nella coda ready.

3.2.2 Scheduling della CPU

Il ruolo di un CPU scheduler è di decidere quale processo allocare in un core, tra quelli disponibili nella ready queue. In aggiunta, deve sapere quando rimuovere un processo dalla CPU per far spazio agli altri. Nel caso di un processo I/O-bound, il processo può essere rimosso nel momento di un’interruzione. Nel caso di un processo CPU-bound, il processo viene tipicamente rimosso all’esaurimento di un limite di tempo programmato, per far eseguire anche gli altri processi.

Alcuni sistemi utilizzano la tecnica dello swapping per cui a volte è vantaggioso spostare un processo dalla memoria centrale a quella secondaria per ridurre il grado di multiprogramming. A seguire verrà re-inserito in memoria ed eseguito.

3.2.3 Cambio di contesto

Quando accade un’interruzione, il contesto del processo in esecuzione viene salvato e rimosso dalla CPU. Il contesto è salvato nel PCB e un nuovo processo viene allocato nella CPU. Questo evento viene chiamato cambio di contesto (context switch). Il context switch, occupa tempo di CPU, generando un overhead. Per tale motivo dev’essere gestito in maniera efficiente e dipende dalla velocità di comunicazione con la memoria, dal numero di registri da copiare, etc. In generale, più il s.o. è complesso, più il context switch richiederà tempo.

3.3 Operazioni sui processi

In questa sezione andremo a spiegare i meccanismi dietro le operazioni principali eseguibili sui processi.

3.3.1 Creazione di processi

Come detto, un processo può creare altri processi, che possono a loro volta creare altri processi e così via, andando a formare un albero di processi. Ogni processo è identificabile tramite un identificatore di processo (Process Identifier, PID), un numero intero. Nei sistemi UNIX solitamente il processo alla radice dell’albero è init() mentre su Linux viene spesso rimpiazzato con systemd().

Quando un processo crea un processo figlio, questo richiederà delle risorse per completare il proprio compito. Il processo genitore potrà quindi decidere di partizionare le risorse con il figlio o di condividerle. Il figlio può anche chiedere risorse direttamente al s.o. ma vincolare le risorse disponibili a quelle permesse al genitore permette di evitare un overload delle risorse in seguito all’eventuale creazione di numerosi processi figlio. In aggiunta, il processo genitore potrebbe dover passare dei parametri al processo figlio per eseguire il compito assegnato. Alternativamente, è il s.o. ad occuparsi di passare le risorse.

Alla creazione del processo, il genitore può attendere la sua esecuzione o eseguire in parallelo col figlio. In aggiunta, il figlio può essere un duplicato del padre (stesso programma e dati), oppure avere un nuovo programma caricato.

Nei sistemi UNIX un nuovo processo è creato usando fork(). Il processo figlio è una copia dello spazio degli indirizzi del processo padre per facilitare la loro comunicazione. Il codice di ritorno dell’operazione è 0 per il figlio e il PID del figlio per il padre.

Una volta effettuato il fork, uno dei due processi chiama exec() per rimpiazzare la memoria del processo con un nuovo programma. Un nuovo file binario viene caricato in memoria e lo spazio di memoria che contiene l’exec viene eliminato. Utilizzando questo metodo i processi hanno prima la possibilità di comunicare e poi di essere indipendenti. Ovviamente, exec() può non essere chiamato: in questo caso entrambi i processi eseguono lo stesso codice con copie dei dati separate.

Qui sotto riportiamo un esempio di programma che crea un nuovo processo con fork() (Fig. 3.8 del Silberschatz)

#include <sys/types.h>
#include <stdio.h>
#include <unistd.h>

int main()
{
 pid_t pid;

 /* fork a child process */
 pid = fork();

 if (pid < 0) { /* error occurred */
 fprintf(stderr, "Fork Failed");
 return 1;
 }
 else if (pid == 0) { /* child process */
 execlp("/bin/ls", "ls", NULL);
 }
 else { /* parent process */
 /* parent will wait for the child to complete */
 wait(NULL);
 printf("Child Complete");
 }

 return 0;
}

3.3.2 Terminazione dei processi

Un processo termina quando esegue la chiamata di sistema exit() e chiede al s.o. di eliminarlo. Solitamente il processo ritorna un valore al processo genitore, tramite la chiamata di sistema wait(). Tutte le risorse del processo vengono deallocate.

A volte è possibile che un processo termini un altro processo tramite una chiamata di sistema apposita. Ciò può avvenire per vari motivi:

Il processo figlio ha superato la quota di risorse a esso assegnata
Il compito del processo figlio non è più richiesto
Il processo genitore sta terminando e il s.o. è stato istruito a terminare anche i processi figli a esso associati

La terminazione di processi figli a seguito di quella del genitore si chiama terminazione a cascata ed è una scelta di design in alcuni s.o.

Nei sistemi UNIX, exit() viene chiamato di default, anche se non è presente nel programma. Quando un processo viene terminato, la sua entry nella tabella dei processi deve rimanere finché il processo genitore non chiama wait() e recupera i valori di ritorno.

Parliamo di processo figlio zombie quando esso termina e attende che la wait() del genitore venga eseguita. Solitamente il periodo di attesa è breve.
Parliamo di processo figlio orfano quando il genitore termina senza aver eseguito la wait(). In questo caso i sistemi UNIX assegnano l’orfano al processo init (systemd nel caso di alcuni sistemi Linux), che si occupa di chiamare periodicamente wait() per eseguire la terminazione corretta dei processi.

3.4 Comunicazione tra processi

Un processo che non condivide dati con altri processi è detto indipendente. Un processo che interagisce con altri processi è detto cooperativo. Ci sono vari motivi per permettere ai processi di cooperare:

Condivisione delle informazioni
Velocità computazionale: ottenuto partizionando un task in molteplici sottotask che possono essere eseguiti in parallelo
Modularità: che garantisce più controllo e facilità di modifica

I processi cooperativi richiedono un meccanismo di comunicazione tra processi (InterProcess communication, IPC). I due modelli fondamentali di comunicazione sono

Memoria condivisa: una parte di memoria viene appunto condivisa tra i processi che sono liberi di scambiarsi le informazioni. È l’alternativa più veloce. Le memoria viene settata con una chiamata di sistema e poi tutti gli accessi vengono trattati come accessi alla memoria.
Passaggio di messaggi: attraverso chiamate di sistema, i processi si inviano messaggi con cui si scambiano i dati. È un metodo efficiente per inviare dati di piccola mole.

3.4.1 IPC nei sistemi a memoria condivisa

Nel modello di comunicazione a memoria condivisa i processi chiedono al s.o. di condividere parte della memoria. Il s.o. autorizza la richiesta e lascia ai processi la responsabilità di gestione della memoria condivisa. I processi devono occuparsi del tipo e della collocazione dei dati, inoltre sono responsabili di non scrivere nella stessa locazione contemporaneamente.

Il paradigma comunemente utilizzato per introdurre il concetto è quello di consumatore/produttore. Un processo produce dati che vengono poi consumati da un altro processo (p.e. un compilatore produce assembly, consumato da un assemblatore). Per il suo funzionamento, è necessario uno spazio di memoria condivisa (buffer) tra due processi e un meccanismo che prevenga il consumatore dal consumare dati non ancora prodotti.

Si possono utilizzare due tipi di buffer:

Illimitato: il consumatore può dover attendere prodotti, ma il produttore può produrne quanti ne vuole
Limitato: sia il consumatore che il produttore devono attendere rispettivamente in caso di buffer vuoto o pieno

Può accadere talvolta che il produttore e il consumatore vogliano utilizzare contemporaneamente il buffer. In questo caso è necessario sincronizzare i processi.

3.4.2 IPC in sistemi a scambio di messaggi

Nel modello a scambio di messaggi i due processi comunicano senza la necessità di una memoria condivisa. È un meccanismo particolarmente utilizzato in ambienti distribuiti con più calcolatori, ad esempio per implementare una chat.

Le due operazioni fondamentali sono l’invio (send(message)) e la ricezione (receive(message)). I messaggi possono avere lunghezza:

Fissa: elementare a livello di sistema, ma più complicato da gestire dal punto di vista applicativo
Variabile: complesso a livello di sistema, ma più semplice dal punto di vista applicativo.

Il componente logico fondamentale per implementare questo paradigma è il canale di comunicazione. Ci sono almeno tre caratteristiche nello sviluppo del canale di comunicazione, che caratterizzano il canale: naming, sincronizzazione e buffering.

3.4.2.1 Naming

Per la comunicazione è necessario disporre che i processi possano essere nominati da altri processi. La comunicazione in base al naming si divide in:

Diretta: i processi comunicano tra di loro direttamente. Questo tipo di comunicazione avviene in due modi:
- simmetrica: comunicante deve esplicitamente indicare il ricevente o il trasmittente della comunicazione. Dato un processo ricevente P e un mittente Q le primitive sono send(P, msg) receive(Q, msg). Il canale di comunicazione ha le seguenti proprietà:
  - Una connessione viene stabilita automaticamente tra ogni coppia di processi che vuole comunicare. I processi devono conoscere la loro reciproca identità per comunicare
  - Un canale è associato esattamente a due processi
  - Tra ogni coppia di processi esiste esattamente un canale
- asimmetrica: solamente il mittente indica il ricevente. Le primitive sono send(P, msg) e receive(id, msg), dove id è l’identificatore del processo con cui la comunicazione ha avuto inizio.

Lo svantaggio della comunicazione diretta è che gli identificatori devono essere esplicitamente definiti e il cambio di nome di un processo richiede di cercare tutte le sue occorrenze e di modificarle di conseguenza.

Indiretta: i processi inviano e ricevono messaggi da caselle di posta (mailbox) o porte (port). Una mailbox è essenzialmente un oggetto con un identificatore che riceve messaggi. Un processo può comunicare con un altro processo inviando messaggi nella mailbox apposita. Per una comunicazione reciproca è necessaria una mailbox condivisa. Data una mailbox A, le primitive sono send(A, msg) e receive(A, msg). Il canale di comunicazione ha le seguenti proprietà:
- Una connessione viene stabilita tra coppie di processi solo se hanno una mailbox condivisa
- Un canale può essere associato a più processi
- Tra ogni coppia di processi possono esistere più canali (uno per mailbox)

Supponiamo tre processi P1, P2, P3 che condividono una mailbox. P1 invia un messaggio. P2 e P3 eseguono la ricezione. Chi ottiene il messaggio. Ci sono tre possibilità per risolvere il problema:

Permettere connessioni solo tra due processi al massimo
Permettere di eseguire una receive solamente a un processo per volta
Definire una policy per la gestione dei conflitti (p.e. alternare i processi riceventi)

Una mailbox può essere posseduta da un processo o dal s.o. Nel primo caso la mailbox è nello spazio di memoria del processo e distinguiamo tra proprietario (solo ricevente) e utente (solo mittente), in maniera da evitare confusione. Quando il processo termina, la mailbox sparisce e ogni processo che voglia ancora inviare messaggi dev’essere notificato dell’eliminazione della mailbox.

La mailbox a livello di s.o. è indipendente e non associata ad alcun processo. Il s.o. deve essere in grado di creare ed eliminare una mailbox e inviare e ricevere messaggi tramite la mailbox.

3.4.2.2 Sincronizzazione

La comunicazione tra processi avviene tramite le primitive send() e receive(). Lo scambio di messaggi può avvenire in due maniere:

Sincrono/bloccante: nel caso dell’invio, il processo mittente si blocca fino alla ricezione del messaggio da parte del ricevente. Nel caso della ricezione il processo ricevente si blocca fino a un nuovo messaggio in arrivo.
Asincrono/non-bloccante: nel caso dell’invio, il processo mittente invia il messaggio e continua l’esecuzione. Nel caso della ricezione il processo ricevente recupera il messaggio oppure null se non c’è alcun messaggio.

Se entrambi invio e ricezione sono bloccanti abbiamo un cosiddetto rendezvous tra il mittente e il ricevente, che risolve il problema produttore/consumatore.

3.4.2.3 Buffering

I messaggi scambiati dai processi risiedono in code temporanee. Tali code possono essere implementate in tre maniere:

Capacità zero: non avendo capacità i messaggi non possono essere accodati e il mittente deve bloccarsi finché il messaggio inviato non è stato ricevuto
Capacità limitata: permette al massimo n messaggi nella coda, oltre i quali il mittente si blocca
Capacità illimitata: la coda ha lunghezza potenzialmente infinita e il mittente non si blocca mai

Il primo caso è a volte chiamato senza buffering mentre gli altri due con buffering automatico.

3.4.3 Pipe

Una pipe è un meccanismo UNIX che agisce come canale di comunicazione tra processi. Le scelte di design per una pipe sono:

La comunicazione è unidirezionale o bidirezionale?
Se la comunicazione è bidirezionale, è half duplex (i dati viaggiano solo in una direzione alla volta) o full duplex (i dati viaggiano in entrambe le direzioni)?
Deve esistere una relazione (del tipo genitore-figlio) tra i processi di comunicazione?
Le pipe possono comunicare in rete o solo all’interno della macchina?

Esistono due tipi di pipe, convenzionali e named.

3.4.3.1 Pipe convenzionali

Queste pipe unidirezionali utilizzano il paradigma produttore/consumatore e possiedono quindi un’estremità dedicata alla scrittura (write-end) e un’estremità dedicata alla lettura (read-end). Per il caso bidirezionale servono due pipe. I sistemi UNIX permettono la creazione di due pipe alla volta (una per scrittura e una per lettura) che vengono gestite come un file (quindi con read e write). Queste pipe richiedono la distinzione tra genitore e figlio e quindi possono essere utilizzate solo all’interno della stessa macchina. Una volta che i processi finiscono di comunicare la pipe convenzionale viene eliminata.

3.4.3.2 Named pipe

Queste pipe bidirezionali sono più potenti delle convenzionali e non richiedono la distinzione genitore figlio. Una volta creata una named pipe diversi processi possono utilizzarla per comunicare e la pipe non viene eliminata al termine delle comunicazioni. Nei sistemi UNIX le named pipe sono dette FIFO e vengono trattate come file. Nonostante la bidirezionalità, la comunicazione è half duplex e quindi le FIFO vengono create a coppie come con le pipe convenzionali. I processi devono risiedere nella stessa macchina.

Nel caso due processi risiedano su due macchine diverse è necessario creare una socket.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 3.

Gestione dei processi

Thu, 14 Mar 2024 00:00:00 +0000

Concetto di processo

Lo stato di un processo è rappresentato dal suo contatore di programma (program counter) e i valori presenti nei registri del processore. La struttura di un processo è composta di:

Sezione di testo: il codice eseguibile
Sezione dati: le variabili globali
Heap: la memoria allocata dinamicamente in esecuzione
Stack: una locazione temporanea per i dati usati nell’invocazione di funzioni (p.e. parametri, indirizzi di ritorno, variabili locali)

Stati di processo

Un processo può trovarsi nei seguenti stati:

Nuovo: il processo è stato creato
Esecuzione (running): le istruzioni stanno venendo eseguite
Attesa (waiting): il processo sta attendendo un evento (p.e. I/O)
Pronto (ready): il processo è in attesa di essere assegnato a un processore
Terminato: il processo ha finito l’esecuzione

Questi nomi sono arbitrari e variano in base al s.o. Solamente un processo per core può essere in stato di esecuzione.

Blocco di controllo del processo

Ogni processo è rappresentato nel s.o. da un blocco di controllo (Process Control Block, PCB, o Task Control Block, TCB), contenente:

Stato del processo: uno degli stati sopra descritti
Contatore di programma: per tenere traccia dell’istruzione da eseguire
Registri della CPU: di molteplice natura (p.e. accumulatori, indici di registro, puntatori a stack, registri general purpose, informazioni sulle condizioni del codice, etc.). È informazione che va salvata in caso di interruzioni.
Informazioni sullo scheduling di CPU: per determinare quando il processo verrà eseguito (p.e. priorità del processo, puntatori a code di scheduling, etc.)
Informazioni sulla gestione della memoria: legate alle locazioni della memoria usate dal processo
Informazioni di accounting: p.e. il numero di CPU, i limiti di tempo, l’identificatore di job o processo, etc.
Informazioni sullo stato dell’I/O: p.e. la lista dei dispositivi I/O allocati al processo, la lista dei file in uso, etc.

Thread

Scheduling dei processi

Due concetti fondamentali ruotano attorno alla schedulazione dei processi:

Il multiprogramming permette alla CPU di essere sempre occupata con altri programmi, anche durante gli interrupt.
Il time sharing permette di eseguire tutti i processi per brevi lassi di tempo, alternandoli, in maniera che l’utente possa interagirci senza ritardi. Per determinare quale processo eseguire in un determinato istante, è necessario un process scheduler.

Per accomodare queste due scelte di design, è bene trattare i processi distinguendoli in due categorie:

I/O-bound per processi che fanno molte operazioni di I/O
CPU-bound per processo che utilizzano molto la CPU

Infine il numero di processi correntemente in memoria viene chiamato grado di multiprogramming.

Code di scheduling

In attesa di un evento (p.e. I/O). In questo caso viene messo nella coda wait e, quando pronto, di nuovo nella coda ready.
Creazione di un processo figlio (child process). Anche in questo caso il processo genitore (parent process) viene messo nella coda wait in attesa che il processo figlio finisca l’esecuzione, per poi venire rimesso nella coda ready.
Rimozione dal core di esecuzione, che può avvenire per via di un interrupt o all’esaurimento del tempo di esecuzione (time slice) allocato al processo. In questo caso il processo viene spostato nella coda ready.

Scheduling della CPU

Cambio di contesto

Operazioni sui processi

In questa sezione andremo a spiegare i meccanismi dietro le operazioni principali eseguibili sui processi.

Creazione di processi

Qui sotto riportiamo un esempio di programma che crea un nuovo processo con fork() (Fig. 3.8 del Silberschatz)

#include <sys/types.h>
#include <stdio.h>
#include <unistd.h>

int main()
{
 pid_t pid;

 /* fork a child process */
 pid = fork();

 if (pid < 0) { /* error occurred */
 fprintf(stderr, "Fork Failed");
 return 1;
 }
 else if (pid == 0) { /* child process */
 execlp("/bin/ls", "ls", NULL);
 }
 else { /* parent process */
 /* parent will wait for the child to complete */
 wait(NULL);
 printf("Child Complete");
 }

 return 0;
}

Terminazione dei processi

A volte è possibile che un processo termini un altro processo tramite una chiamata di sistema apposita. Ciò può avvenire per varie motivi:

Il processo figlio ha superato la quota di risorse a esso assegnata
Il compito del processo figlio non è più richiesto
Il processo genitore sta terminando e il s.o. è stato istruito a terminare anche i processi figli a esso associati

La terminazione di processi figli a seguito di quella del genitore si chiama terminazione a cascata ed è una scelta di design in alcuni s.o.

Parliamo di processo figlio zombie quando esso termina e attende che la wait() del genitore venga eseguita. Solitamente il periodo di attesa è breve.
Parliamo di processo figlio orfano quando il genitore termina senza aver eseguito la wait(). In questo caso i sistemi UNIX assegnano l’orfano al processo init (systemd nel caso di alcuni sistemi Linux), che si occupa di chiamare periodicamente wait() per eseguire la terminazione corretta dei processi.

Comunicazione tra processi

Condivisione delle informazioni
Velocità computazionale: ottenuto partizionando un task in molteplici sottotask che possono essere eseguiti in parallelo
Modularità: che garantisce più controllo e facilità di modifica

I processi cooperativi richiedono un meccanismo di comunicazione tra processi (InterProcess communication, IPC). I due modelli fondamentali di comunicazione sono

Memoria condivisa: una parte di memoria viene appunto condivisa tra i processi che sono liberi di scambiarsi le informazioni. È l’alternativa più veloce. Le memoria viene settata con una chiamata di sistema e poi tutti gli accessi vengono trattati come accessi alla memoria.
Passaggio di messaggi: attraverso chiamate di sistema, i processi si inviano messaggi con cui si scambiano i dati. È un metodo efficiente per inviare dati di piccola mole.

IPC nei sistemi a memoria condivisa

Si possono utilizzare due tipi di buffer:

Illimitato: il consumatore può dover attendere prodotti, ma il produttore può produrne quanti ne vuole
Limitato: sia il consumatore che il produttore devono attendere rispettivamente in caso di buffer vuoto o pieno

Può accadere talvolta che il produttore e il consumatore vogliano utilizzare contemporaneamente il buffer. In questo caso è necessario sincronizzare i processi.

IPC in sistemi a scambio di messaggi

Le due operazioni fondamentali sono l’invio (send(message)) e la ricezione (receive(message)). I messaggi possono avere lunghezza:

Fissa: elementare a livello di sistema, ma più complicato da gestire dal punto di vista applicativo
Variabile: complesso a livello di sistema, ma più semplice dal punto di vista applicativo.

Naming

Per comunicare è necessario disporre che i processi possano essere nominati da altri processi. La comunicazione in base al naming si divide in:

Diretta: i processi comunicano tra di loro direttamente. Questo tipo di comunicazione avviene in due modi:
- simmetrica: comunicante deve esplicitamente indicare il ricevente o il trasmittente della comunicazione. Dato un processo ricevente P e un mittente Q le primitive sono send(P, msg) receive(Q, msg). Il canale di comunicazione ha le seguenti proprietà:
  - Una connessione viene stabilita automaticamente tra ogni coppia di processi che vuole comunicare. I processi devono conoscere la loro reciproca identità per comunicare
  - Un canale è associato esattamente a due processi
  - Tra ogni coppia di processi esiste esattamente un canale
- asimmetrica: solamente il mittente indica il ricevente. Le primitive sono send(P, msg) e receive(id, msg), dove id è l’identificatore del processo con cui la comunicazione ha avuto inizio.

Indiretta: i processi inviano e ricevono messaggi da caselle di posta (mailbox) o porte (port). Una mailbox è essenzialmente un oggetto con un identificatore che riceve messaggi. Un processo può comunicare con un altro processo inviando messaggi nella mailbox apposita. Per una comunicazione reciproca è necessaria una mailbox condivisa. Data una mailbox A, le primitive sono send(A, msg) e receive(A, msg). Il canale di comunicazione ha le seguenti proprietà:
- Una connessione viene stabilita tra coppie di processi solo se hanno una mailbox condivisa
- Un canale può essere associato a più processi
- Tra ogni coppia di processi possono esistere più canali (uno per mailbox)

Supponiamo tre processi P1, P2, P3 che condividono una mailbox. P1 invia un messaggio. P2 e P3 eseguono la ricezione. Chi ottiene il messaggio. Ci sono tre possibilità per risolvere il problema:

Permettere connessioni solo tra due processi al massimo
Permettere di eseguire una receive solamente a un processo per volta
Definire una policy per la gestione dei conflitti (p.e. alternare i processi riceventi)

La mailbox a livello di s.o. è indipendente e non associata ad alcun processo. Il s.o. deve essere in grado di creare ed eliminare una mailbox e inviare e ricevere messaggi tramite la mailbox.

Sincronizzazione

La comunicazione tra processi avviene tramite le primitive send() e receive(). Lo scambio di messaggio può avvenire in due maniere:

Sincrono/bloccante: nel caso dell’invio, il processo mittente si blocca fino alla ricezione del messaggio da parte del ricevente. Nel caso della ricezione il processo ricevente si blocca fino a un nuovo messaggio in arrivo.
Asincrono/non-bloccante: nel caso dell’invio, il processo mittente invia il messaggio e continua l’esecuzione. Nel caso della ricezione il processo ricevente recupera il messaggio oppure null se non c’è alcun messaggio.

Se entrambi invio e ricezione sono bloccanti abbiamo un cosiddetto rendezvous tra il mittente e il ricevente, che risolve il problema produttore/consumatore.

Buffering

I messaggi scambiati dai processi risiedono in code temporanee. Tali code possono essere implementate in tre maniere:

Capacità zero: non avendo capacità i messaggi non possono essere accodati e il mittente deve bloccarsi finché il messaggio inviato non è stato ricevuto
Capacità limitata: permette al massimo n messaggi nella coda, oltre i quali il mittente si blocca
Capacità illimitata: la coda ha lunghezza potenzialmente infinita e il mittente non si blocca mai

Il primo caso è a volte chiamato senza buffering mentre gli altri due con buffering automatico.

Pipe

Una pipe è un meccanismo UNIX che agisce come canale di comunicazione tra processi. Le scelte di design per una pipe sono:

La comunicazione è unidirezionale o bidirezionale?
Se la comunicazione è bidirezionale, è half duplex (i dati viaggiano solo in una direzione alla volta) o full duplex (i dati viaggiano in entrambe le direzioni)?
Deve esistere una relazione (del tipo genitore-figlio) tra i processi di comunicazione?
Le pipe possono comunicare in rete o solo all’interno della macchina?

Esistono due tipi di pipe, convenzionali e named.

Pipe convenzionali

Named pipe

Nel caso due processi risiedano su due macchine diverse è necessario creare una socket.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 3.

4 Thread e concorrenza

Mon, 17 Mar 2025 00:00:00 +0000

In questa lezione andremo a parlare di come parallelizzare i processi per permettere un’esecuzione più efficiente dei task a esso associati. Discuteremo delle criticità principali nello sviluppo di codice parallelizzabile e introdurremo alcune API di programmazione parallela.

4.1 Introduzione

Un thread è l’unità base d’uso della CPU e comprende:

Identificatore (ID)
Contatore di programma
Insieme di registri
Stack

Condivide con gli altri thread:

Sezione di codice
Sezione dati
Risorse di sistema

Un processo tradizionale, viene chiamato processo pesante (heavyweight process) ed è composto da un solo thread. Un processo multithread svolge più compiti parallelamente.

4.1.1 Motivazioni

Di seguito forniamo alcuni esempi di applicazioni multithread:

Un’applicazione che processa dei file in una cartella, può utilizzare i thread per processare più file contemporaneamente.
Un browser può utilizzare un thread per rappresentare immagini e testo e un altro thread per scaricare i dati dalla rete
Un word processor può avere un thread per la rappresentazione del testo e uno per ricevere l’input da tastiera
Un server che deve gestire le interazioni di molti client. Invece di istanziare lo stesso programma per ogni cliente, creando un overhead, il server potrebbe creare un singolo processo che a ogni nuova connessione crea un thread per gestirla parallelamente.

La maggior parte dei kernel dei s.o. è multithread, con ogni thread preposto all’esecuzione di un’attività specifica (p.e. gestione dei dispositivi, memoria, interruzioni, etc.).

Il multithreading può essere applicato anche su algoritmi per l’ordinamento, gli alberi o i grafi, oppure su problemi più specializzati di data mining, grafica o intelligenza artificiale 🤖

4.1.2 Vantaggi

I vantaggi principali del multithreading sono:

Tempo di risposta: il multithreading rende un’applicazione interattiva, anche se parte di essa è bloccata nell’esecuzione di alcuni task. Questa caratteristica è utile soprattutto nella programmazione di GUI.
Condivisione delle risorse: i processi possono condividere risorse solo attraverso IPC. I thread tuttavia condividono la memoria e le risorse di default.
Economia: assegnare memoria e risorse per la creazione di nuovi processi e eseguire context switch è costoso. Con i thread il costo viene abbattuto.
Scalabilità: I vantaggi della programmazione multithread sono ancora maggiori nelle architetture multiprocessore dove i thread possono essere eseguiti su diversi core di elaborazione.

4.2 Programmazione multicore

Il multithreading è stato sviluppato appositamente per sfruttare al meglio i sistemi multicore. Tuttavia, è possibile utilizzare il multithreading anche su sistemi a singola CPU, semplicemente i thread eseguono in maniera sequenziale. In questo senso possiamo distinguere due caratteristiche di un sistema:

Concorrenza (concurrency): il sistema supporta più di un compito, portando avanti tutti i compiti insieme (p.e. alternandoli o parallelizzandoli).
Parallelismo (parallelism): il sistema supporta l’esecuzione parallela di più task simultaneamente.

Di conseguenza un sistema parallelo è sempre concorrente, ma non vale necessariamente il contrario

4.3 Sfide nella programmazione

In generale, la programmazione parallela presenta cinque sfide:

Identificare i task: esaminare l’applicazione per comprendere quali parti del codice sono parallelizzabili.
Bilanciamento: garantire che il compito principale sia equamente diviso tra i task.
Suddivisione dei dati: similmente ai task, anche i dati devono essere equamente divisi tra i task.
Dipendenze dei dati: nel caso in cui i dati siano condivisi tra più task, bisogna garantire sincronizzazione durante la loro manipolazione.
Test e debugging: un algoritmo parallelo presenta molteplici sequenze di esecuzione, per tale motivo è richiesta particolare attenzione e cura nel testing e nel debugging.

4.4 Modello multithreading

Il supporto ai thread può essere fornito a livello di utente o di kernel. Praticamente tutti i sistemi operativi moderni supportano i thread a livello di kernel. Ci possono essere tre relazioni tra thread utente e kernel.

4.4.1 Modello da molti a uno

Questo modello mappa molteplici thread utente a un singolo thread kernel. La gestione dei thread viene effettuata a livello della libreria ed è efficiente. Non è possibile, tuttavia, eseguire i thread utente in parallelo poiché, ogni volta che un thread utente fa una chiamata di sistema bloccante, gli altri devono aspettare la sua esecuzione.

4.4.2 Modello da uno a uno

Questo modello mappa un thread utente a un singolo thread kernel. Questo design permette più concorrenza del modello precedente dal momento che quando un thread fa una chiamata di sistema bloccante, gli altri thread possono comunque eseguire su thread kernel separati. È anche possibile eseguire i thread in parallelo. C’è tuttavia un overhead nella creazione del thread kernel e questo può peggiorare le performance quando devono essere creati molti thread utente. Per tale motivo alcuni s.o. limitano il numero massimo di thread kernel al numero di core del calcolatore.

È un modello comunemente usato nei s.o. Linux e Windows.

4.4.3 Modello da molti a molti

Questo modello mappa molteplici thread utente a molteplici thread kernel. In generale, i thread kernel sono in numero minore dei thread utente per garantire efficienza. Quando un thread utente fa un operazione bloccante, il s.o. può creare un nuovo thread kernel per far proseguire l’esecuzione.

Una variante di questo modello è il modello a due livelli, che permette anche la creazione di singole coppie utente-kernel, come nel modello uno-a-uno.

4.5 Librerie dei thread

Una libreria dei thread fornisce un API per creare e gestire thread. Ci sono due approcci nella sua implementazione.

Il primo consiste nel fornire una libreria interamente a livello utente, senza supporto del kernel. Il secondo consiste nel implementare una libreria che si interfaccia col kernel, con il codice, i dati e le strutture dati nello spazio del kernel.

Le tre librerie principali di thread sono POSIX Pthreads (ilvello utente e sistema), Windows (sistema) e Java (utente ma tipicamente implementata con thread library a livello di sistema). Per le librerie POSIX e Windows ogni dato dichiarato a livello globale è a disposizione di tutti i thread.

4.5.1 Threading sincrono/asincrono

Secondo questa categorizzazione esistono due tipologie di threading:

Sincrono: quando un processo genitore genera uno o più thread figli, deve aspettare il termine della loro esecuzione prima di riprendere a eseguire.
Asincrono: quando un processo genitore genera un thread figlio, il genitore continua con l’esecuzione, in maniera indipendente. È una tecnica comunemente utilizzata per il design di interfacce responsive.

Ci concentreremo sul thread sincrono, che è più interessante e complesso da gestire.

4.5.2 Pthreads

Qui sotto riportiamo un esempio (Fig. 4.13 del Silberschatz) di creazione di un singolo thread per l’esecuzione di una funzione runner.

#include <pthread.h>
#include <stdio.h>

#include <stdlib.h>

int sum; /* this data is shared by the thread(s) */
void *runner(void *param); /* threads call this function */

int main(int argc, char *argv[])
{
 pthread_t tid; /* the thread identifier */
 pthread_attr_t attr; /* set of thread attributes */

 /* set the default attributes of the thread */
 pthread_attr_init(&attr);
 /* create the thread */
 pthread_create(&tid, &attr, runner, argv[1]);
 /* wait for the thread to exit */
 pthread_join(tid, NULL);

 printf("sum = %d∖n", sum);
}

/* The thread will execute in this function */
void *runner(void *param)
{
 int i, upper = atoi(param);
 sum = 0;

 for (i = 1; i <= upper; i++)
 sum += i;

 pthread_exit(0);
}

pthread_t e pthread_attr_t sono i tipi per la creazione del thread e dei suoi attributi
pthread_attr_init si occupa dell’inizializzazione degli attributi del thread (in questo caso lasciati ai valori di default)
pthread_create crea il thread, gli assegna gli attributi, il codice da eseguire (runner) e gli argomenti della funzione (argv[1])
ptrhead_join permette al processo genitore di attendere l’esecuzione del thread figlio

Notate che sum è dichiarata a livello globale, e non è quindi necessario passarla al thread figlio. Per fare la join di diversi processi figlio il seguente snippet (Fig. 4.13 del Silberschatz) illustra come fare.

#define NUM THREADS 10

/* an array of threads to be joined upon */
pthread t workers[NUM THREADS];

for (int i = 0; i < NUM THREADS; i++)
 pthread_join(workers[i], NULL);

4.6 Threading implicito

La crescita continua dei processori multicore, rende inevitabilmente più complesso lo sviluppo di codice parallelo e più difficile la verifica della correttezza di un programma, in quanto un codice parallelo può presentare molteplici path di esecuzione.

Una soluzione al problema consiste nell’threading implicito, ovvero il trasferimento della logica di threading e parallelismo dal lato sviluppatore a quello del compilatore e delle librerie run-time. Allo sviluppatore, in questo caso, è richiesto di definire dei task che siano parallelizzabili e di utilizzare poi degli strumenti appositi per la loro parallelizzazione automatica.

4.6.1 Gruppi di thread

La creazione continuativa di molteplici thread per risolvere task può presentare due criticità. Innanzitutto, creare ed eliminare molti thread genera un overhead nel sistema. Inoltre il numero di thread potrebbe esplodere e deteriorare le performance generali del sistema.

Per ovviare al problema è possibile stabilire un gruppo di thread (thread pool), ovvero una struttura dati che viene inizializzata solamente una volta e che contiene un numero fisso di thread. L’esecuzione avviene nel seguente modo:

Un task che dev’essere eseguito viene sottomesso alla thread pool
Un thread disponibile viene “svegliato” e assegnato all’esecuzione del task. Se non ci sono thread disponibili, il task viene accodato
Il thread esegue il task e, una volta completato, ritorna nella pool in attesa di nuovi task da eseguire

I thread pool offrono alcuni vantaggi:

Non c’è overhead dovuto alla continua creazione di thread.
Il numero di thread disponibili è limitato e quindi controllato.
È possibile pianificare l’esecuzione del task dopo un periodo di tempo o periodicamente.

Il numero di thread può essere impostato euristicamente, basandosi sul numero di core, sulla memoria disponibile, etc. Alcune thread pool più sofisticate possono regolare dinamicamente il numero massimo di thread.

4.6.2 Fork join

Con questa strategia un processo genitore genera vari processi figli, attende la terminazione della loro esecuzione e poi combina i risultati parziali per ottenere il risultato finale. Questo modello è implementato nella librera Java di thread, ma è un ottimo candidato per fare implicit threading. Una libreria gestisce il numero di thread da creare ed è responsabile di assegnare i task ai thread. È simile al modello thread pool, ma è sincrono. È possibile sviluppare anche un approccio divide et impera, in cui i task vengono spezzettati in ulteriori sottotask.

4.6.3 OpenMP

OpenMP è un’API in C/C++ per programmazione parallela in ambienti a memoria condivisa. Lo sviluppatore può identificare regioni parallele, ovvero blocchi di codice che possono eseguire in parallelo, con direttive del compilatore che effettivamente parallelizzano il codice.

4.7 Problemi di programmazione multithreading

In questa sezione discutiamo di alcuni problemi che possono sorgere con i programmi multithreaded.

4.7.1 `fork()` e `exec()`

Se un thread chiama fork(), il nuovo processo deve duplicare tutti i thread o solo uno? Alcuni sistemi UNIX utilizzano due versioni di fork(). Se exec() è chiamata immediatamente dopo una fork, la duplicazione di tutti i thread non è necessaria poiché il programma in esecuzione sarà rimpiazzato con quello specificato da exec(). In caso contrario, i thread saranno duplicati.

4.7.2 Gestione dei segnali

I segnali sono utilizzati in UNIX per notificare un processo che un particolare evento è accaduto. Il pattern è il seguente:

Un segnale viene generato quando un evento accade
Un segnale viene mandato al processo
Una volta inviato, il segnale viene gestito

Esempi di segnali sincroni includono accessi illegali alla memoria e divisioni per 0. Vengono mandati allo stesso processo che ha fatto l’operazione che ha generato il segnale.

Esempi di segnali asincroni includono la terminazione del processo con una specifica combinazione di tasti (p.e. ctrl + C in UNIX) o per tempo limite raggiunto. Sono generati da eventi esterni al processo.

Ogni segnale è associato a un gestore del segnale di default che il kernel esegue quando gestisce il segnale. L’azione di default può essere sovrascritta con un gestore del segnale definito dall’utente. Il segnale può essere gestito ignorandolo ma anche terminando il processo.

Gestire segnali in programmi single-thread è semplice, mentre le cose si complicano con programmi multithreaded. Quando un segnale viene inviato a un thread, abbiamo quattro possibilità per la sua gestione:

Inviare il segnale solamente al thread al quale il segnale si applica
Inviare il segnale a ogni thread del processo
Inviare il segnale a certi thread del processo
Assegnare un thread specifico per ricevere tutti i segnali del processo

Nel caso di segnali sincroni, il segnale viene inviato solo al thread che lo ha generato. Il comportamento con i segnali asincroni è, invece, variabile. Per esempio nel caso di una terminazione con combinazione di tasti, il segnale va inviato a tutti i thread.

In UNIX, i thread possono bloccare alcuni segnali. Quando viene emesso un segnale asincrono, questo può venire inviato a tutti i thread che non lo bloccano, tuttavia, siccome i segnali devono essere gestiti solo una volta, viene inviato solo al primo thread che non lo blocca.

4.7.3 Cancellazione dei thread

La cancellazione dei thread consiste nel terminare un thread prima che questo abbia completato l’esecuzione (p.e. più thread concorrono alla ricerca di un file, uno lo trova e gli altri vengono cancellati).

Un thread che va cancellato è spesso chiamato thread target. La cancellazione avviene in due modi possibili:

Cancellazione asincrona: un thread termina immediatamente un altro thread
Cancellazione posticipata: un thread controlla periodicamente se deve terminare, permettendogli di terminare in maniera ordinata.

La difficoltà nella cancellazione avviene con la gestione delle risorse allocate al thread terminato, che vengono solo parzialmente liberate, specialmente nel caso di cancellazione asincrona. Un altro caso critico è la terminazione di un thread nel mezzo di un update della memoria condivisa. Con la cancellazione posticipata la terminazione è più facile da gestire e può essere effettuata in contesti di codice sicuri.

In Pthreads, un thread può impostare il suo stato di cancellazione con tre opzioni:

Off: il thread non può essere cancellato
Deferred: cancellazione posticipata (default)
Asynchronous: cancellazione asincrona

In aggiunta Pthreads, ha una funzione di gestione pulizia da invocare prima che un thread venga cancellato per rilasciare tutte le sue risorse. In Linux, la cancellazione è gestita attraverso segnali.

4.7.4 Dati locali dei thread

A volte può capitare che un thread necessiti di una copia privata di certi dati, chiamati dati specifici dei thread (o TLS) (p.e. l’ID di una particolare richiesta che il thread sta svolgendo).

La differenza tra variabili locali e TLS è che le prime risiedono nello scope di una funzione mentre i secondi sono visibili attraverso tutte le chiamate.

4.7.5 Attivazione dello scheduler

Nel modello molti a molti, viene spesso implementato una sorta di scheduler per l’assegnazione dei thread utente ai thread kernel. Questa struttura intermedia viene chiamata processo leggero (LWP) ed è una sorta di processore virtuale a cui l’applicazione può chiedere lo scheduling di un thread. Ciascun LWP è associato a un thread kernel e se quest’ultimo si blocca anche il relativo LWP si blocca con il conseguente blocco dei thread utente a esso associati.

Il tipo di applicazione determina il numero di LWP necessari. Un processo CPU bound con esecuzione su singolo processore avrà bisogno di un solo LWP, mentre un processo I/O bound avrà bisogno di molteplici LWP.

Uno dei modelli di comunicazione si chiama attivazione dello scheduler che si basa sul meccanismo di upcall. Il kernel usa le upcall per informare l’applicazione se si verificano determinati eventi come l’imminente blocco di un thread utente. Il procedimento è il seguente:

Un thread sta per bloccarsi
Il kernel invia un’upcall all’applicazione e identifica il thread bloccante
Il kernel assegna all’applicazione un nuovo LWP
L’applicazione esegue un gestore della upcall sul nuovo LWP
Il gestore salva lo stato del thread bloccante e rilascia il processore virtuale su cui era stato eseguito
Il gestore pianifica l’esecuzione di un altro thread sul nuovo LWP

Quando si verifica l’evento bloccante:

Il kernel fa un’altra upcall alla libreria per comunicare che il thread bloccato è nuovamente attivo
L’applicazione esegue un gestore della upcall
Il kernel può decidere di creare un nuovo LWP per questa upcall o di sottrarne uno a un thread utente per prelazione
L’applicazione contrassegna il thread precedentemente bloccato come pronto per l’esecuzione ed esegue l’algoritmo di scheduling

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 4.

Thread e concorrenza

Mon, 18 Mar 2024 00:00:00 +0000

Introduzione

Un thread è l’unità base d’uso della CPU e comprende:

Identificatore (ID)
Contatore di programma
Insieme di registri
Stack

Condivide con gli altri thread:

Sezione di codice
Sezione dati
Risorse di sistema

Un processo tradizionale, viene chiamato processo pesante (heavyweight process) ed è composto da un solo thread. Un processo multithread svolge più compiti parallelamente.

Motivazioni

Di seguito forniamo alcuni esempi di applicazioni multithread:

Un’applicazione che crea processa i file in una cartella separatamente, può utilizzare i thread per processare più file contemporaneamente.
Un browser può utilizzare un thread per rappresentare immagini e testo e un altro thread per scaricare i dati dalla rete
Un word processor può avere un thread per la rappresentazione del testo e uno per ricevere l’input da tastiera
Un server che deve gestire le interazioni di molti client. Invece di istanziare lo stesso programma per ogni cliente, creando un overhead, il server potrebbe creare un singolo processo che a ogni nuova connessione crea un thread per gestirla parallelamente.

La maggior parte dei kernel dei s.o. è multithread, con ogni thread preposto all’esecuzione di un’attività specifica (p.e. gestione dei dispositivi, memoria, interruzioni, etc.).

Il multithreading può essere applicato anche su algoritmi per l’ordinamento, gli alberi o i grafi, oppure su problemi più specializzati di data mining, grafica o intelligenza artificiale 🤖

Vantaggi

I vantaggi principali del multithreading sono:

Tempo di risposta: il multithreading rende un’applicazione interattiva, anche se parte di essa è bloccata nell’esecuzione di alcuni task. Questa caratteristica è utile soprattutto nella programmazione di GUI.
Condivisione delle risorse: i processi possono condividere risorse solo attraverso IPC. I thread tuttavia condividono la memoria e le risorse di default.
Economia: assegnare memoria e risorse per la creazione di nuovi processi e eseguire context switch è costoso. Con i thread il costo viene abbattuto.
Scalabilità: I vantaggi della programmazione multithread sono ancora maggiori nelle architetture multiprocessore dove i thread possono essere eseguiti su diversi core di elaborazione.

Programmazione multicore

Concorrenza (concurrency): il sistema supporta più di un compito, portando avanti tutti i compiti insieme (p.e. alternandoli o parallelizzandoli).
Parallelismo (parallelism): il sistema supporta l’esecuzione parallela di più task simultaneamente.

Di conseguenza un sistema parallelo è sempre concorrente, ma non vale necessariamente il contrario

Sfide nella programmazione

In generale, quando si programmazione parallela, abbiamo cinque sfide:

Identificare i task: esaminare l’applicazione per comprendere quali parti del codice sono parallelizzabili
Bilanciamento: garantire che il compito principale sia equamente diviso tra i task
Suddivisione dei dati: similmente ai task, anche i dati devono essere equamente divisi tra i task
Dipendenze dei dati: nel caso dei dati siano condivisi tra più task, bisogna garantire una sincronizzazione nella loro manipolazione
Test e debugging: un algoritmo parallelo presenta molteplici sequenze di esecuzione, per tale motivo è richiesta particolare attenzione e cura nel testing e nel debugging

Modello multithreading

Modello da molti a uno

Modello da uno a uno

È un modello comunemente usato nei s.o. Linux e Windows.

Modello da molti a molti

Una variante di questo modello è il modello a due livelli, che permette anche la creazione di singole coppie utente-kernel, come nel modello uno-a-uno.

Librerie dei thread

Una libreria dei thread fornisce un API per creare e gestire thread. Ci sono due approcci nella sua implementazione.

Threading sincrono/asincrono

Secondo questa categorizzazione esistono due tipologie di threading:

Sincrono: quando un processo genitore genera uno o più thread figli, deve aspettare il termine della loro esecuzione prima di riprendere a eseguire.
Asincrono: quando un processo genitore genera un thread figlio, il genitore continua con l’esecuzione, in maniera indipendente. È una tecnica comunemente utilizzata per il design di interfacce responsive.

Ci concentreremo sul thread sincrono, che è più interessante e complesso da gestire.

Pthreads

Qui sotto riportiamo un esempio (Fig. 4.13 del Silberschatz) di creazione di un singolo thread per l’esecuzione di una funzione runner.

#include <pthread.h>
#include <stdio.h>

#include <stdlib.h>

int sum; /* this data is shared by the thread(s) */
void *runner(void *param); /* threads call this function */

int main(int argc, char *argv[])
{
 pthread_t tid; /* the thread identifier */
 pthread_attr_t attr; /* set of thread attributes */

 /* set the default attributes of the thread */
 pthread_attr_init(&attr);
 /* create the thread */
 pthread_create(&tid, &attr, runner, argv[1]);
 /* wait for the thread to exit */
 pthread_join(tid,NULL);

 printf("sum = %d∖n",sum);
}

/* The thread will execute in this function */
void *runner(void *param)
{
 int i, upper = atoi(param);
 sum = 0;

 for (i = 1; i <= upper; i++)
 sum += i;

 pthread_exit(0);
}

pthread_t e pthread_attr_t sono i tipi per la creazione del thread e dei suoi attributi
pthread_attr_init si occupa dell’inizializzazione degli attributi del thread (in questo caso lasciati ai valori di default)
pthread_create crea il thread, gli assegna gli attributi, il codice da eseguire (runner) e gli argmoenti della funzione (argv[1])
ptrhead_join permette al processo genitore di attendere l’esecuzione del thread figlio

#define NUM THREADS 10

/* an array of threads to be joined upon */
pthread t workers[NUM THREADS];

for (int i = 0; i < NUM THREADS; i++)
 pthread_join(workers[i], NULL);

Threading implicito

Una soluzione al problema consiste nell’threading implicito, ovvero il trasferimento della logica di threading e parallelismo dal lato sviluppatore a quello del compilatore e delle librerie run-time. Alloo sviluppatore, in questo caso, è richiesto di definire dei task che siano parallelizzabili e di utilizzare poi degli strumenti appositi per la loro parallelizzazione automatica.

Gruppi di thread

Un task che dev’essere eseguito viene sottomesso alla thread pool
Un thread disponibile viene “svegliato” e assegnato all’esecuzione del task. Se non ci sono thread disponibili, il task viene accodato
Il thread esegue il task e, una volta completato, ritorna nella pool in attesa di nuovi task da eseguire

I thread pool offrono i seguenti vantaggi:

Non c’è overhead di creazione di thread
Il numero di thread disponibili è limitato e quindi controllato
È possibile pianificare l’esecuzione del task dopo un periodo di tempo o periodicamente

Fork join

OpenMP

Problemi di programmazione multithreading

In questa sezione discutiamo di alcuni problemi che possono sorgere con i programmi multithreaded.

fork() e exec()

Se un thread chiama fork(), deve il nuovo processo duplicare tutti i thread o solo uno? Alcuni sistemi UNIX utilizzano due versioni di fork(). Se exec() è chiamata immediatamente dopo una fork, la duplicazione di tutti i thread non è necessaria poiché il programma in esecuzione sarà rimpiazzato con quello specificato da exec(). In caso contrario, i thread saranno duplicati.

Gestione dei segnali

I segnali sono utilizzati in UNIX per notificare un processo che un particolare evento è accaduto. Il pattern è il seguente:

Un segnale viene generato quando un evento accade
Un segnale viene mandato al processo
Una volta inviato, il segnale viene gestito

Esempi di segnali sincroni includono accessi illegali alla memoria e divisioni per 0. Vengono mandati allo stesso processo che ha fatto l’operazione che ha generato il segnale.

Inviare il segnale solamente al thread al quale il segnale si applica
Inviare il segnale a ogni thread del processo
Inviare il segnale a certi thread del processo
Assegnare un thread specifico per ricevere tutti i segnali del processo

Cancellazione dei thread

Un thread che va cancellato è spesso chiamato thread target. La cancellazione avviene in due modi possibili:

Cancellazione asincrona: un thread termina immediatamente un altro thread
Cancellazione posticipata: un thread controlla periodicamente se deve terminare, permettendogli di terminare in maniera ordinata.

In Pthreads, un thread può impostare il suo stato di cancellazione con tre opzioni:

Off: il thread non può essere cancellato
Deferred: cancellazione posticipata (default)
Asynchronous: cancellazione asincrona

Dati locali dei thread

La differenza tra variabili locali e TLS è che le prime risiedono nello scope di una funzione mentre i secondi sono visibili attraverso tutte le chiamate.

Attivazione dello scheduler

Uno dei modelli comunicazione è conosciuto come attivazione dello scheduler che si basa sul meccanismo di upcall. Il kernel usa le upcall per informare l’applicazione se si verificano determinati eventi come l’imminente blocco di un thread utente. Il procedimento è il seguente:

Un thread sta per bloccarsi
Il kernel invia un’upcall all’applicazione e identifica il thread bloccante
Il kernel assegna all’applicazione un nuovo LWP
L’applicazione esegue un gestore della upcall sul nuovo LWP
Il gestore salva lo stato del thread bloccante e rilascia il processore virtuale su cui era stato eseguito
Il gestore pianifica l’esecuzione di un altro thread sul nuovo LWP

Quando si verifica l’evento bloccante:

Il kernel fa un’altra upcall alla libreria per comunicare che il thread bloccato è nuovamente attivo
L’applicazione esegue un gestore della upcall
Il kernel può decidere di creare un nuovo LWP per questa upcall o di sottrarne uno a un thread utente per prelazione
L’applicazione contrassegna il thread precedentemente bloccato come pronto per l’esecuzione ed esegue l’algoritmo di scheduling

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 4.

5 Scheduling della CPU

Thu, 20 Mar 2025 00:00:00 +0000

In questa lezione andremo a vedere alcuni degli algoritmi di scheduling dei processi nella CPU, per rendere più efficiente e fluida l’esperienza utente nell’utilizzo del calcolatore. Prima di iniziare specifichiamo che:

Scheduling dei processi e scheduling dei thread sono due locuzioni spesso considerate equivalenti. Le utilizzeremo tuttavia per identificare due concetti diversi
L’unità di base di computazione è il core, che risiede in una CPU, tuttavia utilizzeremo la locuzione generica più comune “eseguire su CPU” per intendere l’esecuzione su un suo core

5.1 Concetti fondamentali

Come detto in precedenza, l’obiettivo della multiprogrammazione è di avere sempre un processo in CPU, in modo da massimizzarne il suo utilizzo. Quando ad esempio un processo è in attesa di un evento o della gestione di una richiesta I/O, la CPU carica un altro processo e lo esegue nel frattempo. La scelta del processo da eseguire in CPU è chiamato scheduling della CPU.

Lo scheduling è una funzione fonamentale dei s.o. e quasi tutte le risorse sono sottoposte a scheduling.

5.1.1 Ciclicità delle fasi d’elaborazione e di I/O

L’esecuzione di un processo è composta di due stati:

Ciclo d’elaborazione: svolto dalla CPU
Attesa completamento operazioni di I/O

Il processo alterna sequenze di elaborazioni della CPU (CPU burst) con sequenze di operazioni di I/O (I/O burst). L’ultima CPU burst si conclude con una richiesta di terminazione del processo. Analisi sui processi hanno evidenziato che la maggior parte dei CPU burst sono brevi. Un processo I/O bound produce CPU burst relativamente brevi, mentre un processo CPU bound ne produce di molto lunghe. Questo è un principio da tenere a mente nello sviluppo di algoritmi di scheduling.

5.1.2 Scheduler di CPU

Il CPU scheduler si occupa della selezione di un processo da eseguire in CPU, prendendone uno dalla coda dei processi che sono in stato ready. I record nella coda sono generalmente i process control block dei processi. La coda non è necessariamente FIFO, come andremo a vedere.

5.1.3 Scheduling prioritario e non-prioritario

Le decisioni di scheduling possono essere prese in una di queste quattro situazioni:

Un processo passa dallo stato di esecuzione a quello di waiting
Un processo passa dallo stato di esecuzione a quello di ready
Un processo passa dallo stato di attesa a quello di ready
Un processo termina

Per i casi 1. e 4. non c’è scelta, un nuovo processo dev’essere eseguito. In questo caso si parla di scheduling non-prioritario o cooperativo. Il processo tiene la CPU finché non termina o passa allo stato di waiting.

Per i casi 2. 3. si parla invece di scheduling prioritario. Virtualmente, tutti i sistemi operativi moderni possiedono questa policy, che può risultare in race condition quando i dati sono condivisi tra più processi. Esempio di race condition: Un processo che sta aggiornando dei dati viene soppiantato da un altro processo più prioritario che legge i dati.

Un problema simile può accadere col kernel quando sta eseguendo una modifica alle sue strutture dati (p.e. la coda I/O) per conto di un processo. Se questo viene soppiantato nel mezzo della modifica e il kernel ha bisogno di modificare successivamente la struttura, otteniamo un’altra race condition.

È possibile utilizzare un kernel non prioritario, tuttavia questa scelta non è adatta per i sistemi real-time. Un kernel prioritario, d’altro canto, richiede dei meccanismi di prevenzione delle race condition, come i mutex. I sistemi operativi moderni sono tutti prioritari.

5.1.4 Dispatcher

Il dispatcher è il componente preposto a dare il controllo della CPU al processo in corso. I suoi compiti sono:

Context switching
Cambio in modalità utente
Saltare all’istruzione giusta quando viene ripresa l’esecuzione di un vecchio processo

Il tempo che trascorre tra il terminare un processo ed eseguirne un altro è chiamato latenza di dispatch. È possibile monitorare i context switch, che si dividono in:

Volontari: quando un processo lascia la CPU perché attende delle risorse attualmente non disponibili
Non volontari: quando la CPU viene presa e assegnata a un altro processo, per esempio per scadenza tempo massimo o per prelazione di un processo verso il corrente.

5.2 Criteri di scheduling

I criteri per lo scheduling della CPU possono essere molteplici. Tra questi abbiamo:

Utilizzo della CPU: Vogliamo tenere la CPU più occupata possibile. L’utilizzo della CPU può variare tra $0%$ a $100%$, ma nella pratica sta nel range $40-90%$. Questa misura va massimizzata
Troughput: è la misura del numero di processi completati per unità di tempo. Un alto throughput indica che molti processi di breve durata sono stati completati. Questa misura va massimizzata
Tempo di turnaround: è il tempo di esecuzione di un processo, dalla sua sottomissione alla sua terminazione, compresi i tempi di attesa. Questa misura va minimizzata
Tempo di attesa: è il tempo speso da un processo in attesa nella coda di ready. Questa misura va minimizzata
Tempo di risposta: nei sistemi interattivi, dove un processo può continuare a produrre output mentre gli output precedenti sono resi disponibili all’utente, il tempo di turaround non è indicativo delle performance. Per tale motivo si può utilizzare il tempo di risposta dalla sottomissione di una richiesta al suo completamento. Questa misura va minimizzata

Nei sistemi interattivi, è più importante minimizzare la varianza del tempo di risposta rispetto alla media, dal momento che è più desiderabile avere un sistema con tempi di risposta prevedibili, rispetto a uno con tempi di risposta brevi in media ma più variabili. Purtroppo non è stato fatto molto lavoro a riguardo

La nostra misura di riferimento sarà il tempo medio di attesa.

5.3 Algoritmi di scheduling

In questa sezione iniziamo a parlare dei principali algoritmi di scheduling. Per semplicità li descriviamo in un contesto a CPU singola.

5.3.1 Scheduling first-come, first-served

Con lo scheduling First-Come, First-Served (FCFS) il processo che ha chiesto per primo la CPU verrà sempre eseguito per primo. L’implementazione è facilmente gestita con una coda FIFO. Il processo entra in coda e quando la CPU si libera, il processo in testa viene rimosso dalla coda e messo in esecuzione.

Lo svantaggio di FCFS è che il tempo medio di attesa è lungo e molto vario. In aggiunta, consideriamo il caso in cui abbiamo molti processi I/O bound seguiti da un processo CPU bound:

I processi I/O bound effettuano un’operazione di I/O e liberano la CPU
Il processo CPU bound entra in CPU
I processi I/O bound finiscono l’operazione e vanno in coda ready attendendo che la CPU si liberi (le prestazioni degradano)
Il processo CPU bound fa una chiamata I/O
I processi I/O accedono di nuovo alla CPU e finiscono in fretta
Nel frattempo il processo CPU bound va in testa alla coda e riempie di nuovo la CPU (le prestazioni degradano)

Questo fenomeno è chiamato effetto convoglio. FCFS è particolarmente inappropriato per sistemi interattivi.

5.3.2 Scheduling shortest-job-first

Con lo scheduling Shortest-Job-First (SJF), ogni processo viene associato alla lunghezza della prossima CPU burst. Quando la CPU è disponibile il processo più corto in questi termini viene mandato in esecuzione. Un nome più corretto sarebbe shortest-next-CPU-burst.

Si può dimostrare che questo algoritmo è ottimale in termini di tempo medio di attesa, tuttavia non è implementabile a livello di scheduling CPU perché non è possibile conoscere a priori il tempo di esecuzione del prossimo CPU burst. A tal proposito, possamo predire il tempo di burst basandoci su quelli precedenti del processo. Si usa tipicamente una media esponenziale

$$ \tau_{n + 1} = \alpha t_n + (1 - \alpha)\tau_n. $$

$\tau_n$ contiene la storia precedente, mentre $t_n$ è il valore più recente. Se espandiamo l’espressione, diventa chiaro perché la media è chiamata esponenziale

$$ \tau_{n + 1} = \alpha t_n + (1 - \alpha)\alpha t_{n - 1} + \dots + (1 - \alpha)^j\alpha t_{n - j} + \dots + (1 - \alpha)^{n + 1} \tau_0 $$

L’algoritmo SJF può essere prioritario o non-prioritario. Nel caso arrivasse in coda un processo con CPU burst più breve di del tempo rimasto al processo correntemente in esecuzione, è possibile lasciare che quest’ultimo venga soppiantato dal nuovo arrivato oppure no. In caso di prelazione l’algoritmo viene chiamato anche shortest-remaining-time first

5.3.3 Scheduling round-robin

Lo scheduling round robin (RR) è simile a FCFS ma viene aggiunta la prelazione dei processi per poterli soppiantare in CPU. Lo scheduler di CPU prende il primo processo dalla coda ready e imposta un tempo limite di un quanto di tempo. Se il CPU burst del processo è più lungo del quanto, il processo viene tolto dalla CPU e messo in coda.

Il tempo medio di attesa è generalmente lungo. Più il quanto di tempo è lungo più RR si comporterà come FCFS. Con quanti brevi, molto tempo di CPU verrà speso in context switch. Come regola, è bene che che l'80% del CPU burst sia più corto del quanto di tempo.

5.3.4 Scheduling con priorità

L’algoritmo SJF è un caso speciale di scheduling con priorità. Una priorità è associata al processo e la CPU è allocata al processo più prioritario. Alcuni s.o. definiscono l’ordine di priorità in maniera decrescente, altri in maniera crescente. Assegneremo la priorità più alta al valore 1.

Le priorità possono essere definite internamente o esternamente. Le priorità interne sono quantità misurabili come i tempi limite, i requisiti di memoria, i numeri di file aperti o il rapporto tra I/O burst medio e CPU burst medio. Le priorità esterne sono impostate con criteri esterni al s.o. come l’importanza del processo, l’ammontare di fondi pagati per l’utilizzo del computer, il dipartimento che sponsorizza il lavoro e altri fattori, spesso politici.

Lo scheduling con priorità può essere prioritario o non prioritario. Quando un processo arriva alla coda di ready, e la sua priorità è maggiore di quella del processo in esecuzione, il processo prioritario soppianta quello in CPU oppure viene messo semplicemente in testa alla coda, in base al tipo di scheduling.

Un problema che può accadere è il blocco infinito o starvation, che accade quando un processo con priorità bassa potrebbe non riuscire ad accedere alla CPU. Per risolvere il problema è possibile ricorrere all’invecchiamento che aumenta la priorità di un processo in base al tempo che trascorre in attesa.

È possibile combinare round robin con priority scheduling, in modo che i processi con la stessa priorità vengano eseguiti col primo algoritmo.

5.3.5 Scheduling a code multilivello

Un’altra tecnica per fare scheduling è quella di creare una coda per ogni livello di priorità. Questo approccio, chiamato a code multilivello, funziona bene anche quando priority scheduling è combinato con round robin. Questo modello può essere utilizzato anche per partizionare i processi in base al loro tipo, per esempio separando i processi foreground da quelli background.

I primi sono interattivi e possono beneficiare di scheduling round robin. Per i secondi, FCFS è più adatto.

In aggiunta ci dev’essere uno scheduling tra le code, che è comunemente implementato come prelazione a priorità fissa.

Ecco un esempio:

Processi real-time
Processi di sistema
Processi interattivi
Processi batch

Un’altra possibilità è quella di assegnare dei time slice per ogni coda, così che tutti i processi possano eseguire. Per esempio, i processi foreground potrebbero ricevere un 80% del tempo e quelli background il restante 20%.

5.3.6 Scheduling a code multilivello con retroazione

In questa variante, i processi possono cambiare la coda in cui sono stati inseriti, in base alle caratteristiche dei CPU burst.

Un processo che aspetta troppo in una coda a bassa priorità potrebbe essere mosso in una coda a priorità maggiore. Con questo metodo d’invecchiamento è possibile prevenire la starvation. È possibile anche abbassare la priorità di un processo se questo non viene eseguito entro un tempo limite, favorendo così l’accesso alla CPU per i processi brevi.

Una coda multilivello a feedback è definita dai seguenti parametri:

Il numero di code
L’algoritmo di scheduling per ogni coda
I metodi utilizzati per aggiornare il processo a code diverse da quella di appartenenza
Il metodo utilizzato per decidere in quale coda entra il processo

È l’algoritmo di scheduling più generico.

5.4 Scheduling dei thread

Nei sistemi operativi moderni, ciò che viene mappato nella CPU è solitamente un thread kernel e non un processo. La mappatura thread utente a thread kernel viene invece lasciata agli LWP, assicurandosi di raggruppare tutti i thread dello stesso processo nella competizione per la CPU (Process Contention Scope (PCS)). Per decidere invece quale thread kernel mappare nella CPU, il kernel utilizza il system contention scope. Di solito PCS segue un meccanismo a priorità.

5.5 Scheduling multiprocesso

Con le architetture multiprocessore è possibile fare condivisione del carico (load sharing) in cui molteplici thread possono essere eseguiti in parallelo, complicando tuttavia lo scheduling.

5.5.1 Approcci allo scheduling multiprocesso

Il primo approccio allo scheduling multiprocesso è quello asimmetrico, in cui lo scheduling viene affidato a un unico processore e gli altri eseguono solamente codice. Ciò semplifica il controllo ma il processore principale rischia di creare un bottleneck.

L’approccio standard consiste nello scheduling multiprocesso simmetrico (Symmetric Multiprocessing, SMP), dove lo scheduler di ogni processore sceglie il proprio thread dalla coda di ready e lo esegue. Conseguentemente possiamo avere due casistiche:

Tutti i thread stanno in un’unica coda. In questo caso bisogna evitare che si formino race condition, quando due processori selezionano contemporaneamente lo stesso thread.
Ogni processore ha la sua coda privata. È l’approccio più comune nei sistemi SMP. È importante bilanciare la lunghezza delle code per ogni processore.

5.5.2 Processori multicore

I computer moderni sono sistemi multicore. In questo caso il processore ospita più core di computazione e il s.o. lo vede come una semplice CPU, senza avere accesso all’architettura interna. Questo complica gli algoritmi di scheduling. In particolare, è stato notato che le CPU spendono la maggior parte del loro tempo accedendo ai dati in memoria, che è più lenta. Il problema viene chiamato stallo di memoria e può occupare fino al 50% del tempo di CPU.

Per rimediare al problema i processori moderni hanno implementato sistemi multithreaded, in cui un core ha due thread kernel assegnati. Quando un thread kernel effettua un accesso alla memoria e attende risposta, il core può cambiare l’esecuzione con l’altro thread. In questo caso, il s.o. vede una CPU logica per thread (p.e. un sistema con quattro core, in cui ogni core gestisce due thread, viene considerato dal s.o. come un sistema con 8 CPU logiche).

I processori Intel utilizzano il termine hyper-threading (conosciuto anche come simultaneous threading, SMT) per indicare il supporto a questa metodologia.

In generale ci sono due modi per fare multithreading sui core:

Coarse-grained: il thread viene sostituito solo in caso di eventi a lunga latenza come gli stalli di memoria. Il costo dello scambio tra thread è alto.
Fine-grained: la sostituzione può avvenire potenzialmente a ogni ciclo di istruzione. Il costo dello scambio è più contenuto.

Lo scheduling nei sistemi multicore va fatto a due livelli:

Livello s.o.: il s.o. si occupa di assegnare thread software (utente) ai corrispondenti thread hardware (kernel). Gli algoritmi di schedulimg precedentemente spiegati sono applicabili a questo scopo.
Livello core: riguarda la decisione di quale thread hardware eseguire sul core.

È possibile permettere al s.o. di accedere alla logica a livello core, per permettere un bilanciamento migliore delle prestazioni.

5.5.3 Bilanciamento del carico

Nei sistemi SMP che fanno uso di code private è importante bilanciare il carico di ogni processore in maniera che non ci sia overloading su un singolo processore. Per fare ciò si adottano due strategie, che possono essere implementate insieme nello stesso s.o.:

Push migration: un task si occupa di monitorare i processori e quando trova un processore sovraccarico, ribilancia le code
Pull migration: il task si occupa di spostare dei processi sulle code dei processori idle

Il bilanciamento può essere fatto sul numero di processi per coda o sulle priorità per coda. È comunque un processo delicato che può portare a rallentamenti invece che a miglioramenti.

5.5.4 Predilezione per il processore

Dal momento che un processore ha la sua cache personale, spostare un thread tra processori invaliderebbe la cache e costringerebbe a un update della gerarchia della memoria, un’operazione molto costosa. Questo fenomeno è chiamato predilezione per il processore (processor affinity). Questo problema si verifica con la coda condivisa e non con le code private dove il thread rimane sempre nella stessa coda (a meno che non siano implementate strategie di bilanciamento del carico).

Ci sono due tipi di predilezione:

Soft: un processo viene assegnato a un processore ma può essere spostato dal bilanciamento del carico.
Hard: un processo viene assegnato, tramite chiamata di sistema, a un sottoinsieme di processori sui quali può eseguire

Spesso i s.o. implementano entrambe le predilezioni. Anche l’architettura di memoria può influenzare la predilezione per il processore. Si noti infine come il bilanciamento di carico si contrappone ai vantaggi offerti dalla predilezione per il processore.

5.5.5 Multiprocessing eterogeneo

È possibile implementare architetture i cui core presentano caratteristiche diverse. Per esempio possiamo definire due tipi di core, uno grande che consuma molta energia e un altro piccolo che ne consuma poca. I task lenti potrebbero essere assegnati ai core piccoli per risparmiare sull’energia consumata, un aspetto fondamentale nei sistemi mobile. Questa pratica si chiama Multiprocessing eterogeneo (Heterogeneous Multiprocessing).

5.6 Scheduling real-time della CPU

Lo scheduling real-time può essere diviso in due strategie:

Soft: Un processo critico avrà precedenza rispetto ai non-critici, non vengono però date garanzie sul momento in cui questo verrà eseguito
Hard: Un processo critico verrà eseguito entro una scadenza prefissata, oltre la quale la sua esecuzione è inutile

5.6.1 Minimizzazione della latenza

Un sistema real-time è guidato dagli eventi in tempo reale, che possono accadere a livello sofrware (p.e. un timer) o hardware (p.e. un veicolo controllato a distanza si accorge di essere vicino a un ostacolo). Il sistema deve essere in grado di rispondere con la massima velocità possibile. Chiamiamo latenza relativa all’evento (event latency) il periodo di tempo che intercorre tra l’occorrenza dell’evento e il momento in cui il sistema ne effettua la gestione.

Eventi diversi hanno requisiti di latenza diversi. Le categorie di latenza sono due:

Latenza relativa alle interruzioni: è il periodo di tempo compreso tra la notifica di un’interruzione alla CPU e l’avvio della routine che gestisce l’interruzione. Questa latenza è relativa al tempo complessivamente impiegato per le seguenti fasi:
1. Notifica di un’interruzione
2. La CPU porta a compimento l’operazione corrente
3. La CPU determina il tipo di interruzione
4. Lo stato del processo dev’essere salvato
5. Avvio della procedura di gestione dell’interruzione
Latenza relativa al dispatch: è il periodo di tempo utilizzato dal dispatcher per la terminazione di un processo e l’avvio di un altro processo. Il metodo migliore per minimizzare questa latenza consiste nell’utilizzare un kernel prioritario. La fase di conflitto della latenza relativa al dispatch ha due componenti:
1. Prelazione di ogni processo che esegue nel kernel
2. Rilascio delle risorse necessarie al processo critico da parte dei processi non critici

A seguire, il dispatcher fa lo scheduling del processo critico su una CPU disponibile.

5.6.2 Scheduling basato sulla priorità

Gli s.o. real-time devono supportare uno scheduling di priorità con prelazione. Ciò è necessario per ottenere dei s.o. real-time soft. Per conseguire real-time hard è necessario eseguire i processi entro la loro scadenza prefissata.

Per discutere di questi aspetti è necessario introdurre il concetto di processo periodico, ovvero un processo che richiede la CPU a intervalli costanti (periodi). Una volta che un processo periodico, con periodo $p$ ottiene una CPU, esegue per un lasso di tempo fisso $t$ entro una deadline $d$ che dev’essere eseguita da una CPU. In sintesi, abbiamo che $0 \le t \le d \le p$. La frequenza di un task periodico è quindi $1 / p$.

L’aspetto peculiare di un processo periodico è che deve annunciare la sua scadenza allo scheduler che, utilizzando una tecnica di controllo dell’ammissione (admission control), può ammettere il processo garantendo la sua esecuzione in tempo, o rifiutare la richiesta perché impossibile da eseguire entro la scadenza prefissata.

5.6.3 Scheduling con priorità proporzionale alla frequenza

Questo algoritmo di scheduling organizza task periodici utilizzando una policy a priorità statica con prelazione. Per i task periodici, più il periodo è corto, più la priorità è alta è ciò consente di rispettare più deadlines. Questo scheduling è ottimale poiché se un insieme di processi non può essere pianificato da questo algoritmo, allora non può essere pianificato da nessun altro algoritmo che assegni priorità statiche.

L’algoritmo ha comunque una limitazione: l’utilizzo della CPU è vincolato e non è sempre possibile massimizzare le risorse CPU completamente rispettando le deadline. In particolar, il caso peggiore di utilizzo CPU per lo scheduling di $N$ processi è

$$ N(2^{1/N} - 1). $$

Se l’utilizzo reale della CPU supera questo limite teorico, non è possibile rispettare le scadenze dei processi. Il limite si assesta attorno al $69%$ per $N \rightarrow +\infty$ ($N$ tendente a infinito).

5.6.4 Scheduling EDF

Lo scheduling Earliest-Deadline-First (EDF) assegna priorità dinamicamente secondo le scadenze dei processi. Più vicina è la scadenza, maggiore sarà la priorità assegnata al processo. Ogni volta che un processo entra nella coda di ready notifica la propria scadenza all’algoritmo che potrà assegnare la priorità al processo e modificare quelle degli altri processi.

EDF non si preoccupa della periodicità dei processi e ha il vantaggio di essere teoricamente ottimo, garantendo, idealmente, l’esecuzione di tutti processi entro le proprie scadenze e sfruttando la CPU al 100%. Nella pratica, un rendimento così alto non è possibile per via dei cambi di contesto e della gestione della memoria.

5.6.5 Scheduling a quote proporzionali

Lo scheduling a quote proporzionali opera distribuendo un certo numero di quote $T$ fra tutte le applicazioni. Un’applicazione può ricevere $N$ quote di tempo per avere una frazione $N/T$ del tempo di CPU. Questo scheduling ha bisogno di un meccanismo di controllo dell’ammissione per garantire che ogni applicazione riceva effettivamente le quote di tempo assegnate. Il meccanismo accetterà le richieste dei processi solo se effettivamente ci sono abbastanza quote disponibili.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 5.

Scheduling della CPU

Thu, 28 Mar 2024 00:00:00 +0000

Scheduling dei processi e scheduling dei thread sono due locuzioni spesso considerate equivalente. Le utilizzeremo tuttavia per identificare due concetti diversi
L’unità di base di computazione è il core, che risiede in una CPU, tuttavia utilizzeremo la locuzione generica più comune “eseguire su CPU” per intendere l’esecuzione su un suo core

Concetti fondamentali

Come detto in precedenza, l’obiettivo della mutliprogrammazione è di avere sempre un processo in CPU, in modo da massimizzarne il suo utilizzo. Quando ad esempio un processo è in attesa di un evento o della gestione di una richiesta I/O, la CPU carica un altro processo e lo esegue nel frattempo. La scelta del processo da eseguire in CPU è chiamato scheduling della CPU.

Lo scheduling è una funzione fonamentale dei s.o. e quasi tutte le risorse sono sottoposte a scheduling.

Ciclicità delle fasi d’elaborazione e di I/O

L’esecuzione di un processo è composta di due stati:

Ciclo d’elaborazione: svlto dalla CPU
Attesa completamento operazioni di I/O

Scheduler di CPU

Scheduling prioritario e non-prioritario

Le decisioni di scheduling possono essere prese in una di queste quattro situazioni:

Un processo passa dallo stato di esecuzione a quello di waiting
Un processo passa dallo stato di esecuzione a a quello di ready
Un processo passa dallo stato di attesa a quello di ready
Un processo termina

Dispatcher

Il dispatcher è il componente preposto a dare il controllo della CPU al processo in corso. I suoi compiti sono:

Context switching
Cambio in modalità utente
Saltare all’istruzione giusta quando viene ripresa l’esecuzione di un vecchio processo

Il tempo che trascorre tra il terminare un processo ed eseguirne un altro è chiamato latenza di dispatch. È possibile monitorare i context switch, che si dividono in:

Volontari: quando un processo lascia la CPU perché attende delle risorse attualmente non disponibili
Non volontari: quando la CPU viene presa e assegnata a un altro processo, per esempio per scadenza tempo massimo o per prelazione di un processo verso il corrente.

Criteri di scheduling

I criteri per lo scheduling della CPU possono essere molteplici. Tra questi abbiamo:

Utilizzo della CPU: Vogliamo tenere la CPU più occupata possibile. L’utilizzo della CPU può variare tra $0%$ a $100%$, ma nella pratica sta nel range $40-90%$. Questa misura va massimizzata
Troughput: è la misura del numero di processi completati per unità di tempo. Un alto throughput indica che molti processi di breve durata sono stati completati. Questa misura va massimizzata
Tempo di turnaround: è il tempo di esecuzione di un processo, dalla sua sottomissione alla sua terminazione, compresi i tempi di attesa. Questa misura va minimizzata
Tempo di attesa: è il tempo speso da un processo in attesa nella coda di ready. Questa misura va minimizzata
Tempo di risposta: nei sistemi interattivi, dove un processo può continuare a produrre output mentre gli output precedenti sono resi disponibili all’utente, il tempo di turaround non è indicativo delle performance. Per tale motivo si può utilizzare il tempo di risposta dalla sottomissione di una richiesta al suo completamento. Questa misura va minimizzata

La nostra misura di riferimento sarà il tempo medio di attesa.

Algoritmi di scheduling

In questa sezione iniziamo a parlare dei principali algoritmi di scheduling. Per semplicità li descriviamo in un contesto a CPU singola.

Scheduling first-come, first-served

Lo svantaggio di FCFS è che il tempo medio di attesa è lungo e molto vario. In aggiunta, consideriamo il caso in cui abbiamo molti processi I/O bound seguiti da un processo CPU bound:

I processi I/O bound effettuano un’operazione di I/O e liberano la CPU
Il processo CPU bound entra in CPU
I processi I/O bound finiscono l’operazione e vanno in coda ready attendendo che la CPU si liberi (le prestazioni degradano)
Il processo CPU bound fa una chiamata I/O
I processi I/O accedono di nuovo alla CPU e finiscono in fretta
Nel frattempo il processo CPU bound va in testa alla coda e riempie di nuovo la CPU (le prestazioni degradano)

Questo fenomeno è chiamato effetto convoglio. FCFS è particolarmente inappropriato per sistemi interattivi.

Scheduling shortest-job-first

$\tau_{n + 1} = \alpha t_n + (1 - \alpha)\tau_n$.

$\tau_n$ contiene la storia precedente, mentre $t_n$ è il valore più recente. Se espandiamo l’espressione, diventa chiaro perché la media è chiamata esponenziale

$\tau_{n + 1} = \alpha t_n + (1 - \alpha)\alpha t_{n - 1} + \dots + (1 - \alpha)^j\alpha t_{n - j} + \dots + (1 - \alpha)^{n + 1} \tau_0$

Scheduling round-robin

Scheduling con priorità

È possibile combinare round robin con priority scheduling, in modo che i processi con la stessa priorità vengano eseguiti col primo algoritmo.

Scheduling a code multilivello

I primi sono interattivi e possono beneficiare di scheduling round robin. Per i secondi, FCFS è più adatto.

In aggiunta ci dev’essere uno scheduling tra le code, che è comunemente implementato come prelazione a priorità fissa.

Ecco un esempio:

Processi real-time
Processi di sistema
Processi interattivi
Processi batch

Scheduling a code multilivello con retroazione

In questa variante, i processi possono cambiare la coda in cui sono stati inseriti, in base alle caratteristiche dei CPU burst.

Una coda multilivello a feedback è definita dai seguenti parametri:

Il numero di code
L’algoritmo di scheduling per ogni coda
I metodi utilizzati per aggiornare il processo a code diverse da quella di appartenenza
Il metodo utilizzato per decidere in quale coda entra il processo

È l’algoritmo di scheduling più generico.

Scheduling dei thread

Nei sistemi operativi moderni, ciò che viene mappato nella CPU è solitamente un thread kernel e non un processo. La mappatura thread utente a thread kernel viene invece lasciata agli LWP, assicurandosi di raggruppare tutti i thread dello stesso processo nella competizione per la CPU (process contention scope (PCS)). Per decidere invece quale thread kernel mappare nella CPU, il kernel utilizza il system contention scope. Di solito PCS segue un meccanismo a priorità.

Scheduling multiprocesso

Con le architetture multiprocessore è possibile fare condivisione del carico (load sharing) in cui molteplici thread possono essere eseguiti in parallelo, complicando tuttavia lo scheduling.

Approcci allo scheduling multiprocesso

Tutti i thread stanno in un’unica coda. In questo caso bisogna evitare che si formino race condition, quando due processori selezionano contemporaneamente lo stesso thread.
Ogni processore ha la sua coda privata. È l’approccio più comune nei sistemi SMP. È importante bilanciare la lunghezza delle code per ogni processore.

Processori multicore

Per rimediare al problema i processori moderni hanno implementato sistemi multithreaded, in cui un processore può cambiare thread hardware di esecuzione non appena un thread hardware effettua un accesso alla memoria. Il sistema operativo vede una CPU per thread (p.e. Un sistema con quattro core, in cui ogni core gestisce due thread, viene contato come un sistema a 8 CPU).

I processori Intel utilizzano il termine hyper-threading (conosciuto anche come simultaneous threading, SMT) per indicare il supporto a questa metodologia. In generale ci sono due modi per

In generale ci sono due modi per fare multithreading sui core:

Coarse-grained: il thread viene sostituito solo in caso di eventi a lunga latenza come gli stalli di memoria. Il costo dello scambio tra thread è alto.
Fine-grained: la sostituzione può avvenire potenzialmente a ogni ciclo di istruzione. Il costo dello scambio è più contenuto.

Lo scheduling nei sistemi multicore va fatto a due livelli:

Livello s.o.: il s.o. si occupa di assegnare thread software (utente) ai corrispondenti thread hardware (kernel). Gli algoritmi di schedulimg precedentemente spiegati sono applicabili a questo scopo.
Livello core: concerne la decisione di quale thread hardware eseguire sul core.

È possibile permettere al s.o. di accedere alla logica a livello core, per permettere un bilanciamento migliore delle prestazioni.

Bilanciamento del carico

Push migration: un task si occupa di monitorare i processori e quando trova un processore sovraccarico, ribilancia le code
Pull migration: il task si occupa di spostare dei processi sulle code dei processori idle

Il bilanciamento può essere fatto sul numero di processi per coda o sulle priorità per coda. È comunque un processo delicato che può portare a rallentamenti invece che a miglioramenti.

Predilezione per il processore

Ci sono due tipi di predilezione:

Soft: un processo viene assegnato a un processore ma può essere spostato dal bilanciamento del carico.
Hard: un processo viene assegnato, tramite chiamata di sistema, a un sottoinsieme di processori sui quali può eseguire

Multiprocessing eterogeneo

Scheduling real-time della CPU

Lo scheduling real-time può essere diviso in due strategie:

Soft: Un processo critico avrà precedenza rispetto ai non-critici, non vengono però date garanzie sul momento in cui questo verrà eseguito
Hard: Un processo critico verrà eseguito entro una scadenza prefissata, oltre la quale la sua esecuzione è inutile

Minimizzazione della latenza

Eventi diversi hanno requisiti di latenza diversi. Le categorie di latenza sono due:

Latenza relativa alle interruzioni: è il periodo di tempo compreso tra la notifica di un’interruzione alla CPU e l’avvio della routine che gestisce l’interruzione. Questa latenza è relativa al tempo complessivamente impiegato per le seguenti fasi:
1. Notifica di un’interruzione
2. La CPU porta a compimento l’operazione corrente
3. La CPU determina il tipo di interruzione
4. Lo stato del processo dev’essere salvato
5. Avvio della procedura di gestione dell’interruzione
Latenza relativa al dispatch: è il periodo di tempo utilizzato dal dispatcher per la terminazione di un processo e l’avvio di un altro processo. Il metodo migliore per minimizzare questa latenza consiste nell’utilizzare un kernel prioritario. La fase di conflitto della latenza relativa al dispatch ha due componenti:
1. Prelazione di ogni processo che esegue nel kernel
2. Rilascio delle risorse necessarie al processo critico da parte dei processi non critici

A seguire, il dispatcher fa lo scheduling del processo critico su una CPU disponibile.

Scheduling basato sulla priorità

Scheduling con priorità proporzionale alla frequenza

Questo algoritmo di scheduling organizza task periodico utilizzando una policy a priorità statica con prelazione. Se un processo a bassa priorità sta eseguendo e un processo ad alta priorità è disponibile per essere eseguito, quest’ultimo soppianterà il processo in esecuzione. Per i task periodici, più il periodo è corto, più la priorità è alta è ciò consente di rispettare più deadlines. Questo scheduling è ottimale poiché se un insieme di processi non può essere pianificato da questo algoritmo, allora non può essere pianificato da nessun altro algoritmo che assegni priorità statiche.

Questo algoritmo ha una limitazione: l’utilizzo della CPU è vincolato e non è sempre possibile massimizzare le risorse CPU completamente. Il caso peggiore di utilizzo CPU per lo scheduling di $N$ processi è

$N(2^{1/N} - 1)$.

Scheduling EDF

Scheduling a quote proporzionali

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 5.

6 Sincronizzazione dei processi

Tue, 25 Mar 2025 00:00:00 +0000

In questa lezione andremo a studiare i meccanismi per controllare l’accesso di strutture condivise da parte dei thread, mantenendo l’integrità dei dati.

6.1 Background

Ricordiamo che un processo cooperativo può essere influenzato da altri processi con i quali condivide codice o dati. Questo comportamento può contribuire a generare problemi relativi all’integrità dei dati.

Presentiamo subito un esempio, con il paradigma produttore-consumatore.

Questo è il codice del produttore.

while (true) {
 /* produce an item in next_produced */

 while (count == BUFFER_SIZE)
 ; /* do nothing */

 buffer[in] = next_produced;
 in = (in + 1) % BUFFER_SIZE;
 count++;

}

Questo invece è il codice del consumatore.

while (true) {
 while (count == 0)
 ; /* do nothing */

 next_consumed = buffer[out];
 out = (out + 1) % BUFFER_SIZE;
 count--;

 /* consume the item in next_consumed */

}

Se questi due snippet di codice vengono eseguiti concorrentemente, può accadere che venga eseguita l’operazione count++ e count-- contemporaneamente. Supponiamo che inizialmente il valore di count sia 5. Possono sorgere due casistiche:

Si verificano sequenzialmente le seguenti due istruzioni
- count (valore 5) viene acceduto dal consumatore che esegue count-- (valore 4)
- count (valore 4) viene acceduto dal produttore che esegue count++ (valore 5)
Il risultato finale (valore 5) è corretto. Notate come il produttore possa eseguire prima del consumatore, senza cambiare il risultato finale.
Si verificano sequenzialmente queste istruzioni
- count viene acceduto dal consumatore (valore 5)
- count viene acceduto dal produttore (valore 5)
- Il consumatore esegue count-- (valore 4)
- Il produttore esegue count++ e sovrascrive il valore aggiornato dal consumatore, al quale non ha avuto accesso (valore 6)
Il risultato finale (valore 6) è sbagliato. Notate come possa accadere anche il caso opposto
- count viene acceduto dal consumatore (valore 5)
- count viene acceduto dal produttore (valore 5)
- Il produttore esegue count++ (valore 6)
- Il consumatore esegue count-- (valore 4)
Anche in questo caso il risultato finale (valore 4) è sbagliato.

Le casisitiche sbagliate del punto 2, vengono chiamate race conditions. Per proteggersi da tali fenomeni è necessario garantire che solo un processo alla volta modifichi la variabile condivisa count, sincronizzando i processi.

6.2 Il problema della sezione critica

Iniziamo le nostre considerazioni discutendo del problema della sezione critica. Consideriamo un sistema con $n$ processi $[P_0, \dots, P_{n - 1}]$. Ogni processo ha un segmento di codice chiamato sezione critica, potenzialmente diverso tra i vari processi (p.e. produttore-consumatore), nel quale accede e aggiorna dei dati condivisi. Se vogliamo mantenere l’integrità dei dati, non è possibile lasciare eseguire una sezione critica a due processi concorrentemente.

Per risolvere il problema è quindi necessario progettare un protocollo che sincronizzi l’attività dei processi. Ogni processo deve richiedere l’accesso alla sua sezione, e la parte di codice preposta a questo scopo viene chiamata sezione d’entrata (entry section). Quest’ultima è seguita da una sezione di uscita (exit section). Il codice rimanente è chiamato sezione rimanente (remainder section). Il codice di un processo deve quindi racchiudere la sua sezione critica tra la sezione d’entrata e quella d’uscita.

Una soluzione al problema della sezione critica richiede che siano soddisfatti i seguenti tre requisiti:

Mutua esclusione: se il processo $P_i$ sta eseguendo la sua sezione critica, nessun altro processo può eseguirla in quel momento.
Progresso: se nessun processo sta eseguendo la propria sezione critica (inclusa quella d’uscita) e alcuni processi vogliono entrarci, allora solamente quelli che non stanno eseguendo la sezione rimanente possono partecipare alla selezione in cui si decide chi entrerà. Questa selezione non può essere posticipata indefinitivamente. In altre parole ci deve sempre un progresso fatto dell’algoritmo, o per via di un processo che esegue la sezione critica, o per via del meccanismo di selezione di un nuovo processo per entrare nella sezione critica.
Attesa limitata: esiste un limite al numero di volte in cui gli altri processi possono accedere alla loro sezione critica dopo che un processo ha fatto richiesta di accesso alla propria e prima che tale richiesta venga garantita.

Non facciamo alcuna assunzione sulla velocità dei singoli processi, se non che questa sia non negativa.

Riportiamo due esempi in cui il problema della sezione critica compare:

Una struttura kernel con cui il sistema operativo tiene traccia dei file aperti. Tale struttura può essere modificata quando i processi aprono o chiudono file. Se due processi vogliono aprire lo stesso file, la lista dev’essere sincronizzata per poter evitare race condition.
Due processi genitori eseguono fork(). Il contatore pid da assegnare ai nuovi processi figli dev’essere sincronizzato per evitare che venga assegnato lo stesso pid a entrambi i processi

Il problema della sezione critica può essere risolto facilmente in contesti single-core, evitando gli interrupt quando una variabile condivisa sta venendo aggiornata. Sfortunatamente questa soluzione non è adatta a sistemi multicore dove la notifica della disabilitazione di interrupt a tutti i processori aggiunge un overhead.

6.3 Soluzione di Peterson

Ora illustriamo la classica soluzione al problema della sezione critica: la soluzione di Peterson. Assumiamo due processi $P_i$ e $P_j$. La soluzione di Peterson richiede che i due processi condividano due dati:

int turn;
boolean flag[2];

Se turn == i allora $P_i$ ha il permesso di entrare nella sezione critica. Se flag[i] è impostato a true $P_i$ è pronto per entrare nella sezione critica.

Per entrare nella sezione critica $P_i$ imposta flag[i] = true e poi turn = j indicando, così, che se l’altro processo vuole entrare nella sezione critica può farlo. Se entrambi i processi volessero entrare nella sezione critica nello stesso momento turn conterrebbe il valore i o j e solo uno dei due processi potrebbe effettivamente entrare.

Il codice per il processo $P_i$ è il seguente:

while(true) {
 flag[i] = true;
 turn = j;
 while (flag[j] && turn == j)
 ;

 /* critical section */

 flag[i] = false;

 /* remainder section */
}

La soluzione è corretta poiché rispetta le tre proprietà:

Mutua esclusione: $P_i$ entra nella sua sezione critica solo se flag[j] == false o turn == i. Può accadere che flag[0] == flag[1] == true e che turn venga aggiornato contemporaneamente, tuttavia il suo valore sarà uno soltanto tra i e j garantendo l’accesso alla sezione critica solamente a un processo alla volta.
Progresso: supponiamo che $P_j$ sia nella sezione rimanente e che $P_i$ sia nel ciclo while. Se questa proprietà fosse verificata, solamente $P_i$ potrebbe accedere alla sezione critica, non importa quale processo venga eseguito prima tra $P_i$ e $P_j$. Vediamo le possibili casistiche di esecuzione
- $P_i$ esegue per primo il controllo della condizione nel ciclo while. flag[j] == false quindi viene selezionato per entrare nella sezione critica.
- $P_j$ esegue per primo. Esce dalla sezione rimanente, imposta flag[j] == true e turn = i per poi entrare nel ciclo while. flag[i] == true, poiché $P_i$ è anch’esso nel ciclo while e turn = i, quindi $P_j$ non può entrare nella sezione critica.
È quindi garantito che $P_i$ sia l’unico candidato in selezione per entrare nella sezione critica.
Attesa limitata: dall’esempio precedente possiamo vedere che dopo ogni esecuzione di $P_j$ è garantito che $P_i$ possa eseguire. Quindi $P_i$ deve attendere al massimo un’esecuzione di $P_j$ prima di poter eseguire la sezione critica.

Non è garantito che la soluzione di Peterson funzioni nelle architetture moderne, poiché, per ottimizzare l’esecuzione, i processori possono invertire le istruzioni presenti nel codice. Se le istruzioni flag[i] = true e turn = j fossero scambiate, potrebbe accadere la seguente esecuzione:

$P_i$ imposta turn = j
$P_j$ imposta turn = i e poi flag[j] == true
$P_j$ entra nel ciclo while. flag[i] == false quindi esce dal ciclo while ed entra nella sezione critica
$P_i$ imposta flag[i] == true ed entra nel ciclo while. turn == i quindi esce dal ciclo while ed entra nella sezione critica.

Entrambi i processi sono entrati nella sezione critica. È necessario quindi utilizzare delle API appropriate per gestire la sincronizzazione.

6.4 Supporto hardware per la sincronizzazione

Dopo aver descritto una soluzione software al problema della sezione critica, passiamo ora a discutere di una soluzione hardware.

Barriere di memoria

Un modello di memoria specifica le garanzie della memoria sull’integrità dei dati, in una specifica architettura. In generale, abbiamo due categorie:

Fortemente ordinata: dove una modifica della memoria su un processore è immediatamente visibile agli altri processori
Debolmente ordinata: dove una modifica alla memoria su un processore può non essere immediatamente visibile agli altri processori

Dal momento che i modelli di memoria variano di processore in processore, gli sviluppatori di un kernel non possono fare assunzioni sulla visibilità delle modifiche alla memoria.

Per ovviare al problema, le architetture forniscono istruzioni che possono forzare la notifica e l’aggiornamento di qualunque cambio nella memoria a tutti processori. Tali istruzioni si chiamano barriere di memoria (memory barriers) o recinti di memoria (memory fences). Quando una barriera di memoria viene eseguita, il sistema garantisce che tutte le operazioni di load e store siano completate prima di ogni altra load o store successiva, permettendo una consistenza nel buffer anche in caso di riordinamento della memoria. Per esempio nel seguente codice

x = 100
memory_barrier()
flag = true

viene garantito che x sia assegnato prima di flag. Questa tecnica può essere utilizzata per garantire l’efficacia della soluzione di Peterson. Le barriere di memoria sono operazioni a basso livello, utilizzate solamente dagli sviluppatori di kernel.

6.4.1 Istruzioni hardware

Molti computer moderni forniscono speciali istruzioni hardware per eseguire operazioni di memoria atomiche, il cui contenuto è visto come una singola istruzione non separabile. Facciamo due esempi. Il primo è con un’istruzione atomica test_and_set()

bool test_and_set(bool *target) {
 bool rv = *target;
 *target = true;

 return rv;
}

che ritorna il valore originale di target e poi lo imposta a true. La caratteristica importante è che l’operazione viene eseguita atomicamente, quindi se due di queste istruzioni vengono eseguite simultaneamente su due core differenti, saranno eseguite sequenzialmente, in un qualche ordine arbitrario.

Se il sistema supporta test_and_set() possiamo ad esempio implementare un meccanismo di lock col seguente codice

do {
 while (test_and_set(&lock))
 ; /* do nothing */

 /* critical section */

 lock = false;

 /* remainder section */
} while (true);

Per fare un altro esempio, prendiamo l’istruzione compare_and_swap(), definita nel seguente modo

int compare_and_swap(int *value, int expected, int new_value) {
 int temp = *value;

 if (*value == expected)
 *value = new_value;

 return temp;
}

Questa istruzione si occupa di impostare la variabile value col valore contenuto in new_value, solamente se value == expected. Ancora una volta, l’operazione è considerata atomica dal sistema. La mutua esclusione può essere raggiunta col seguente codice

while (true) {
 while (compare_and_swap(&lock, 0, 1) != 0)
 ; /* do nothing */

 /* critical section */

 lock = 0;

 /* remainder section */
}

Una variabile globale lock viene impostata a 0. Il primo processo che invoca compare_and_swap() imposta lock a 1 e tutte le chiamate successive non modificheranno più il valore, finché il processo entrato nella sezione critica non ne esce ed esegue lock = 0.

Questo algoritmo non garantisce il requisito di attesa limitata, poiché un processo in attesa potrebbe potenzialmente non entrare mai nella sezione critica. Il seguente codice ovvia al problema

while (true) {
 waiting[i] = true;
 key = 1
 while ( waiting[i] && key == 1)
 key = compare_and_swap(&lock, 0, 1);
 waiting[i] = false;

 /* critical section */

 j = (i + 1) % n;
 while ((j != i) && !waiting[j])
 j = (j + 1) % n;

 if (j == i)
 lock = 0;
 else
 waiting[j] = false;

 /* remainder section */
}

La sezione d’entrata permette solamente a un processo di entrare nella sezione critica, che imposterà key = 0 e waiting[i] = false. Una volta eseguita la sezione critica il processo scorre il vettore waiting finché non trova un altro processo con waiting[j] == true oppure scorre tutto il vettore waiting e imposta j = i. In tal caso, esce dal ciclo while della sezione d’uscita e controlla quale delle due condizioni si è verificata. Se non ha trovato processi in attesa, allora j == i e il processo imposta lock = 0, altrimenti imposta waiting[j] = false permettendo al processo j di entrare nella sezione critica. In questo modo, un processo attenderà al massimo $n - 1$ turni prima di entrare nella sezione critica, garantendo il requisito di attesa limitata.

6.4.2 Variabili atomiche

L’istruzione compare_and_swap() viene tipicamente utilizzata per costruire degli strumenti di controllo più complessi, come una variabile atomica che fornisce operazioni atomiche su tipi base di dati, p.e. interi e booleani.

I sistemi che implementano le variabili atomiche, includono delle funzioni per manipolare tali tipi di dato. Riportiamo una funzione la funzione increment(), utile per risolvere il problema dell’aggiornamento di un contatore, come nel paradigma produttore consumatore (è possibile definire una funzione decrement() analoga)

void increment(atomic_int *v)
{
 int temp;

 do {
 temp = *v;
 }
 while (temp != compare_and_swap(v, temp, temp + 1));
}

In questo caso il valore in v va incrementato. Si effettua l’assegnazione di temp = *v e a seguire un aggiornamento di v a temp + 1. Se un altro processo concorrente esegue, invece, compare_and_swap prima del processo corrente, *v è pari a temp + 1. Nel processo corrente, quindi, *v è ora diverso da temp e la condizione nel ciclo while fallisce. Il corpo del ciclo viene rieseguito e il valore di temp viene riassegnato al nuovo valore dentro v, per poi provare di nuovo a eseguire l’incremento.

È importante notare che sebbene le variabili atomiche forniscano aggiornamenti atomici, non risolvono interamente le race condition in tutte le circostanze, Nel paradigma produttore potremmo avere due consumatori che attendono e una coda vuota. Un produttore produce un prodotto impostando una variabile atomica count a 1. I due consumatori escono dal ciclo while di attesa ed entrambi procedono a consumare il prodotto, generando una race condition.

Le variabili atomiche sono utilizzate spesso per singoli aggiornamenti di dati condivisi come i contatori e i generatori di sequenze.

6.4.3 Lock mutex

Le soluzioni finora viste sono complicate e poco accessibili agli sviluppatori di applicazioni. Esistono alcuni strumenti più semplici per risolvere il problema della sezione critica nel software ad alto livello. Uno di questi è il cossiddetto lock mutex (dove mutex sta per mutual exclusion). mutex mette a disposizione due funzioni:

acquire() {
 while (!available)
 ; /* busy wait */
 available = false;
}

che acquisisce un lock.

release() {
 available = true;
}

che rilascia il lock. Le due call devono essere atomiche e possono essere quindi implementate con compare_and_swap().

Lo svantaggio principale dell’implementazione sopracitata è che richiede il meccanismo di busy waiting in cui i processi entrano per attendere il loro turno nell’acquisizione del lock. Ciò consuma cicli CPU senza che vengano eseguite realmente istruzioni e peggiora le prestazioni nei sistemi multiprogramming dove molti processi competono in un singolo core della CPU.

Questo tipo di lock si chiama anche spinlock poiché il processo “gira” (spins) finché il lock non diventa disponibile. Gli spinlock hanno il vantaggio di non richiedere context switch quando un processo attende il lock, nei sistemi multicore. Infatti, nei casi in cui il lock venga tenuto per poco tempo, un thread può “girare” su un core mentre un altro processo esegue la sezione critica su un altro core, senza la necessità di context switch. Per tale motivo gli spinlock sono comunemente usati in molti s.o.

I lock mutex sono considerati i più semplici sistemi di sincronizzazione

6.5 Semafori

Un semaforo è considerato una tecnica più robusta dei mutex per la sincronizzazione dei processi, introdotto dall’informatico olandese Edsger Dijkstra. Un semaforo $S$ è un intero che viene acceduto tramite due operazioni atomiche: wait() e signal(). Spesso le operazioni vengono chiamate anche P (dall’olandese proberen/testare) e V (dall’olandese verhogen/incrementare). Le definizioni delle funzioni sono le seguenti

wait(S) {
 while (S <= 0)
 ; // busy wait
 S--;
}

signal(S) {
 S++;
}

In aggiunta all’atomicità, nel caso della wait() il controllo della condizione deve avvenire senza interruzioni.

6.5.1 Utilizzo dei semafori

Gli s.o. distinguono tra due tipi di semafori

semafori contatori: S può essere maggiore di $1$
semafori binari: S vale al massimo $1$. Il meccanismo è simile a quello dei mutex

I semafori contatori possono essere utilizzati per il controllo dell’accesso a risorse con un numero finito di istanze. Sono inizializzati al numero di risorse disponibili e ogni che viene chiamata wait(), S viene decrementato. Una volta raggiunto lo 0, la wait() diviene bloccante.

Possiamo utilizzare i semafori anche per problemi di sincronizzazione. Consideriamo due processi concorrenti: $P_1$ con codice S1 e $P_2$ con codice S2. Supponiamo che S2 vada eseguito solamente dopo S1. Possiamo implementare la sincronizzazione utilizzando un semaforo condiviso synch, inizializzato a 0. il codice di $P_1$ è

S1;
signal(synch);

mentre quello di $P_2$ è

wait(synch);
S2;

Poiché synch è inizializzato a 0, $P_2$ eseguirà S2 solo dopo che $P_1$ avrà invocato signal(synch), ovvero dopo l’esecuzione di S1.

6.5.2 Implementazione di un semaforo

Le definizioni di wait() e signal() sopra presentate, hanno lo stesso problema di busy waiting dei mutex. Per ovviare al problema possiamo modificare la definizione di wait() facendo in modo che quando il valore del semaforo non è positivo, il processo si sospenda mettendosi nella coda di wait. Il processo viene poi risvegliato con una chiamata signal() che esegue un’operazione di wakeup(), che permette al processo di spostarsi nella coda di ready. L’implementazione del semaforo è la seguente:

typedef struct {
 int value;
 struct process *list;
} semaphore;

Ogni semaforo ha un valore intero e una lista di processi. Quando un processo attende un semaforo, questo viene aggiunto alla lista dei processi. L’operazione signal() rimuove un processo dalla lista e lo risveglia.

L’operazione di wait() è implementata nel seguente modo:

wait(semaphore *S) {
 S -> value--;
 if (S -> value < 0) {
 add this process to S -> list;
 sleep();
 }
}

e l’operazione di signal() è invece:

signal(semaphore *S) {
 S -> value++;
 if (S -> value <= 0) {
 remove a process P from S->list;
 wakeup(P);
 }
}

L’operazione sleep() sospende il processo che lo invoca. L’operazione wakeup() fa riprendere l’esecuzione.

Con questa versione, un semaforo può assumere valori negativi, pari al numero di processi in attesa. La lista di processi può essere implementata con un campo link nel PCB del processo. Per assicurare un’attesa limitata, è possibile utilizzare una coda FIFO, ma qualunque strategia di accodamento va bene.

Per garantire l’atomicità delle operazioni wait() e signal() è necessario inibire gli interrupt durante la loro esecuzione. Nei sistemi multicore, l’inibizione va fatta su tutti i processori, tuttavia ciò può comportare una diminuzione delle performance. Per tale motivo, i sistemi SMP devono fornire anche alternative come compare_and_swap() o gli spinlock.

6.6 Monitor

I semafori e i mutex richiedono un’attenta progettazione del codice. È importante garantire che tutti i processi concorrenti chiamino prima la wait() e poi la signal(). Nel caso di sincronizzazioni complesse con molteplici processi in gioco, l’aderenza a questa regola può essere complicata. Citiamo a tal proposito, i monitor, strumenti a più alto livello che tentano di risolvere questo problema (non li copriremo in questo corso).

6.7 Liveness

Una possibile conseguenza dell’utilizzo di tool di sincronizzazione è quella che un processo attenda indefinitamente prima di accedere alla sezione critica. La liveness si riferisce a un insieme di proprietà che un sistema deve garantire per far sì che i suoi processi procedano. Un fallimento della liveness accade quando un processo non rispetta tali proprietà.

Un semplice esempio è il loop infinito. Una busy wait può rappresentare una possibilità di fallimento della liveness, se non è implementata correttamente.

6.7.1 Deadlock

Un caso particolare di fallimento della liveness è il cosiddetto deadlock, che accade quando in un semaforo due processi attendono un evento generato rispettivamente dall’altro processo. Consideriamo il seguente esempio:

 P0 P1
 wait(S); wait(Q);
 wait(Q); wait(S);
 . .
 . .
 . .
 signal(S); signal(Q);
 signal(Q); signal(S);

Se $P_0$ esegue wait(S) e $P_1$ wait(Q).

Se $P_0$ esegue wait(Q) dovrà attendere che $P_1$ faccia signal(Q)
Se $P_1$ esegue wait(S) dovrà attendere che $P_0$ faccia signal(S)

In questo modo i processi attendono un’operazione che non verrà mai eseguita comportando un deadlock. In generale, un insieme di processi è in deadlock, se ogni processo dell’insieme è in attesa di un evento generato da uno degli altri processi nell’insieme.

6.7.2 Inversione di priorità

Supponiamo di avere tre processi con priorità $L$, $M$, $H$, tali che $L < M < H$. Assumiamo che $H$ richieda una risorsa controllata da un semaforo $S$, attualmente acceduto da $L$. Supponiamo ora che $M$ diventi eseguibile e soppianti il processo $L$. Ora $H$ dovrà aspettare l’esecuzione di $M$ per poter accedere alla risorsa.

Questo problema di liveness è chiamato inversione di priorità (priority inversion) e può accadere soltanto in sistemi con più di due priorità. Tipicamente è possibile evitare questo problema implementando un protocollo di ereditarietà della priorità (priority-inheritance protocol). Con questo meccanismo, se un processo $H$ ad alta priorità richiede una risorsa detenuta da un processo $L$ a bassa priorità, quest’ultimo eredità la priorità del processo $H$ in maniera da prevenire altri processi con priorità media $M$ di poterla richiedere. Una volta concluso l’utilizzo, il processo a bassa priorità torna ad avere la sua priorità originale $L$

6.8 Valutazione

Riportiamo alcune semplici strategie per determinare quale strumento di sincronizzazione usare, tra quelli che abbiamo presentato in questa lezione.

Barriere di memoria e istruzioni atomiche sono tecniche di basso livello, spesso utilizzate per implementare meccanismi di sincronizzazione più sofisticati.

L’approccio compare_and_swap() (CAS) è un meccanismo ottimista in cui una variabile viene aggiornata e solo dopo viene controllato se un altro thread sta aggiornando la variabile. Al contrario il mutex è un approccio pessimistico in quanto si assume che un altro thread stia concorrentemente aggiornando la variabile per cui viene acquisito il lock prima di fare qualunque update. In generale:

Se un lock non è conteso tra i processi, è preferibile una protezione CAS in quanto più veloce
Se un lock viene conteso moderatamente tra i processi, CAS risulterà più veloce della sincronizzazione tradizionale
Se un lock viene conteso spesso tra i processi, la sincronizzazione tradizionale risulterà essere più veloce di quella basata su CAS

In aggiunta, gli interi atomici, essendo molto leggeri, sono spesso utili per aggiornare variabili come contatori condivisi. In generale i lock mutex sono semplici da utilizzare e richiedono meno overhead dei semafori, che a loro volta sono meno pesanti dei monitor.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 6.

Sincronizzazione dei processi

Mon, 08 Apr 2024 00:00:00 +0000

In questa lezione andremo a studiare i meccanismi per controllare l’accesso di strutture condivise da parte dei thread, mantenendo l’integrità dei dati.

Background

Presentiamo subito un esempio, con il paradigma produttore-consumatore.

Questo è il codice del produttore.

while (true) {
 /* produce an item in next_produced */

 while (count == BUFFER_SIZE)
 ; /* do nothing */

 buffer[in] = next_produced;
 in = (in + 1) % BUFFER_SIZE;
 count++;

}

Questo invece è il codice del consumatore.

while (true) {
 while (count == 0)
 ; /* do nothing */

 next_consumed = buffer[out];
 out = (out + 1) % BUFFER_SIZE;
 count--;

 /* consume the item in next_consumed */

}

Si verificano sequenzialmente le seguenti due istruzioni
- count (valore 5) viene acceduto dal consumatore che esegue count-- (valore 4)
- count (valore 4) viene acceduto dal produttore che esegue count++ (valore 5)
Il risultato finale (valore 5) è corretto. Notate come il produttore possa eseguire prima del consumatore, senza cambiare il risultato finale.
Si verificano sequenzialmente queste istruzioni
- count viene acceduto dal consumatore (valore 5)
- count viene acceduto dal produttore (valore 5)
- Il consumatore esegue count-- (valore 4)
- Il produttore esegue count++ e sovrascrive il valore aggiornato dal consumatore, al quale non ha avuto accesso (valore 6)
Il risultato finale (valore 6) è sbagliato. Notate come possa accadere anche il caso opposto
- count viene acceduto dal consumatore (valore 5)
- count viene acceduto dal produttore (valore 5)
- Il produttore esegue count++ (valore 6)
- Il consumatore esegue count-- (valore 4)
Anche in questo caso il risultato finale (valore 4) è sbagliato.

Il problema della sezione critica

Iniziamo le nostre considerazioni discutendo del problema della sezione critica. Consideriamo un sistema con $n$ processi $[P_0, \dots, P_{n - 1}]$. Ogni processo ha un segmento di codice chiamato sezione critica nel quale accede e aggiorna dei dati condivisi. Se vogliamo mantenere l’integrità dei dati, non è possibile lasciare eseguire la sezione critica a due processi concorrentemente.

Il problema della sezione critica consiste nel progettare un protocollo che sincronizzi l’attività dei processi per evitare ciò. Ogni processo deve richiedere l’accesso alla sua sezione, e la parte di codice preposta a questo scopo viene chiamata sezione d’entrata (entry section). Quest’ultima è seguita da una sezione di uscita (exit section). Il codice rimanente è chiamato sezione rimanente (remainder section). Il codice di un processo deve quindi racchiudere la sua sezione critica tra la sezione d’entrata e quella d’uscita.

Una soluzione al problema della sezione critica richiede che siano soddisfatti i seguenti tre requisiti:

Mutua esclusione: se il processo $P_i$ sta eseguendo la sua sezione critica, nessun altro processo può eseguirla in quel momento
Progresso: se nessun processo sta eseguendo la propria sezione critica e alcuni processi vogliono entrarci, allora solamente quelli che non stanno eseguendo la sezione rimanente possono partecipare alla selezione in cui si decide chi entrerà. Questa selezione non può essere posticipata indefinitivamente.
Attesa limitata: esiste un limite al numero di volte in cui gli altri processi possono accedere alla loro sezione critica dopo che un processo ha fatto richiesta di accesso alla propria e prima che tale richiesta venga garantita.

Non facciamo alcuna assunzione sulla velocità dei singoli processi, se non che questa sia non negativa.

Riportiamo due esempi in cui il problema della sezione critica compare:

Una struttura kernel con cui il sistema operativo tiene traccia dei file aperti. Tale struttura può essere modificata quando i processi aprono o chiudono file. Se due processi vogliono aprire lo stesso file, la lista dev’essere sincronizzata per poter evitare race condition.
Due processi genitori eseguono fork(). Il contatore pid da assegnare ai nuovi processi figli dev’essere sincronizzato per evitare che venga assegnato lo stesso pid a entrambi i processi

Esistono due approcci generali al problema e consistono nello sviluppo di:

kernel non-prioritari: non permettono che un processo che esegue nel kernel mode venga soppiantato da un altro processo. Questo kernel non è soggetto a race condition
kernel prioritari: permettono che un processo che esegue nel kernel venga soppiantato. La loro progettazione è particolarmente difficile in architetture SMP, tuttavia la loro interattività garantisce un’esperienza più fluida, specialmente in contesti real-time

Soluzione di Peterson

int turn;
boolean flag[2];

Se turn == i allora $P_i$ ha il permesso di entrare nella sezione critica. Se flag[i] è impostato a true $P_i$ è pronto per entrare nella sezione critica.

Per entrare nella sezione critica $P_i$ imposta flag[i] = true e poi turn = j asserendo che se l’altro processo vuole entrare nella sezione critica può farlo. Se entrambi i processi volessero entrare nella sezione critica nello stesso momento turn conterrebbe il valore i o j e solo uno dei due processi potrebbe effettivamente entrare.

Il codice per il processo $P_i$ è il seguente:

while(true) {
 flag[i] = true;
 turn = j;
 while (flag[j] && turn == j)
 ;

 /* critical section */

 flag[i] = false;

 /* remainder section */
}

La soluzione è corretta poiché rispetta le tre proprietà:

Mutua esclusione: $P_i$ entra nella sua sezione critica solo se flag[j] == false o turn == i. Può accadere che flag[0] == flag[1] == true e che turn venga aggiornato contemporaneamente, tuttavia il suo valore sarà uno soltanto tra i e j garantendo l’accesso alla sezione critica solamente a un processo alla volta.
Progresso: supponiamo che $P_j$ sia nella sezione rimanente e che $P_i$ sia nel ciclo while. Se questa proprietà fosse verificata, solamente $P_i$ potrebbe accedere alla sezione critica, non importa quale processo venga eseguito prima tra $P_i$ e $P_j$. Vediamo le possibili casistiche di esecuzione
- $P_i$ esegue per primo il controllo della condizione nel ciclo while. flag[j] == false quindi viene selezionato per entrare nella sezione critica.
- $P_j$ esegue per primo. Esce dalla sezione rimanente, imposta flag[j] == true e turn = i per poi entrare nel ciclo while. flag[i] == true, poiché $P_i$ è anch’esso nel ciclo while e turn = i, quindi $P_j$ non può entrare nella sezione critica.
È quindi garantito che $P_i$ sia l’unico candidato in selezione per entrare nella sezione critica.
Attesa limitata: dall’esempio precedente possiamo vedere che dopo ogni esecuzione di $P_j$ è garantito che $P_i$ possa eseguire. Quindi $P_i$ deve attendere al massimo un’esecuzione di $P_j$ prima di poter eseguire la sezione critica.

$P_i$ imposta turn = j
$P_j$ imposta turn = i e poi flag[j] == true
$P_j$ entra nel ciclo while. flag[i] == false quindi esce dal ciclo while ed entra nella sezione critica
$P_i$ imposta flag[i] == true ed entra nel ciclo while. turn == i quindi esce dal ciclo while ed entra nella sezione critica.

Entrambi i processi sono entrati nella sezione critica quindi si possono verificare delle race condition. È necessario quindi utilizzare delle API appropriate per gestire la sincronizzazione.

Supporto hardware per la sincronizzazione

Dopo aver descritto una soluzione software al problema della sezione critica, passiamo ora a discutere di una soluzione hardware.

Barriere di memoria

Un modello di memoria specifica le garanzie della memoria sull’integrità dei dati, in una specifica architettura. In generale, abbiamo due categorie:

Fortemente ordinata: dove una modifica della memoria su un processore è immediatamente visibile agli altri processori
Debolmente ordinata: dove una modifica alla memoria su un processore può non essere immediatamente visibile agli altri processori

Dal momento che i modelli di memoria variano di processore in processore, gli sviluppatori di un kernel non possono fare assunzioni sulla visibilità delle modifiche alla memoria.

x = 100
memory_barrier()
flag = true

Istruzioni hardware

boolean test_and_set(boolean *target) {
 boolean rv = *target;
 *target = true;

 return rv;
}

Se il sistema supporta test_and_set() possiamo ad esempio implementare un meccanismo di lock col seguente codice

do {
 while (test_and_set(&lock))
 ; /* do nothing */

 /* critical section */

 lock = false;

 /* remainder section */
} while (true);

Per fare un altro esempio, prendiamo l’istruzione compare_and_swap(), definita nel seguente modo

int compare_and_swap(int *value, int expected, int new_value) {
 int temp = *value;

 if (*value == expected)
 *value = new_value;

 return temp;
}

while (true) {
 while (compare_and_swap(&lock, 0, 1) != 0)
 ; /* do nothing */

 /* critical section */

 lock = 0;

 /* remainder section */
}

Questo algoritmo non garantisce il requisito di attesa limitata, poiché un processo in attesa potrebbe potenzialmente non entrare mai nella sezione critica. Il seguente codice ovvia al problema

while (true) {
 waiting[i] = true;
 key = 1
 while ( waiting[i] && key == 1)
 key = compare_and_swap(&lock, 0, 1);
 waiting[i] = false;

 /* critical section */

 j = (i + 1) % n;
 while ((j != i) && !waiting[j])
 j = (j + 1) % n;

 if (j == i)
 lock = 0;
 else
 waiting[j] = false;

 /* remainder section */
}

Variabili atomiche

I sistemi che implementano le variabili atomiche, includono delle funzioni per manipolare tali tipi di dato, p.e. increment(), definita come segue

void increment(atomic_int *v)
{
 int temp;

 do {
 temp = *v;
 }
 while (temp != compare_and_swap(v, temp, temp + 1));
}

Le variabili atomiche sono utilizzate spesso per singoli aggiornamenti di dati condivisi come i contatori e i generatori di sequenze.

Lock mutex

acquire() {
 while (!available)
 ; /* busy wait */
 available = false;
}

che acquisisce un lock.

release() {
 available = true;
}

che rilascia il lock. Le due call devono essere atomiche e possono essere quindi implementate con compare_and_swap().

I lock mutex sono considerati i più semplici sistemi di sincronizzazione

Semafori

wait(S) {
 while (S <= 0)
 ; // busy wait
 S--;
}

signal(S) {
 S++;
}

In aggiunta all’atomicità, nel caso della wait() il controllo della condizione deve avvenire senza interruzioni.

Utilizzo dei semafori

Gli s.o. distinguono tra due tipi di semafori

semafori contatori: S può essere maggiore di $1$
semafori binari: S vale al massimo $1$. Il meccanismo è simile a quello dei mutex

Possiamo utilizzare i semafori anche per problemi di sincronizzazione. Consideriamo due processi concorrenti: $P_1$ con codice $S_1$ e $P_2$ con codice $S_2$. Supponiamo che $S_2$ vada eseguito solamente dopo $S_1$. Possiamo implementare la sincronizzazione utilizzando un semaforo condiviso synch, inizializzato a 0. il codice di $P_1$ è

S1;
signal(synch);

mentre quello di $P_2$ è

wait(synch);
S2;

Poiché synch è inizializzato a 0, $P_2$ eseguirà $S_2$ solo dopo che $P_1$ avrà invocato signal(synch), ovvero dopo l’esecuzione di $S_1$.

Implementazione di un semaforo

Le definizioni di wait() e signal() sopra presentate, presentano lo stesso problema di busy waiting dei mutex. Per ovviare al problema possiamo modificare la definizione di wait() facendo in modo che quando il valore del semaforo non è positivo, il processo si sospende mettendosi nella coda di wait. Il processo viene poi risvegliato con una chiamata signal() che esegue un’operazione di wakeup(), che permette al processo di spostarsi nella coda di ready. L’implementazione del semaforo è la seguente:

typedef struct {
 int value;
 struct process *list;
} semaphore;

L’operazione di wait() è implementata nel seguente modo:

wait(semaphore *S) {
 S -> value--;
 if (S -> value < 0) {
 add this process to S -> list;
 sleep();
 }
}

e l’operazione di signal() è invece:

signal(semaphore *S) {
 S -> value++;
 if (S -> value <= 0) {
 remove a process P from S->list;
 wakeup(P);
 }
}

L’operazione sleep() sospende il processo che lo invoca. L’operazione wakeup() fa riprendere l’esecuzione.

Monitor

I semafori e i mutex richiedono un’attenta progettazione del codice. È importante garantire che tutti i processi concorrenti chiamino prima la wait() e poi la signal(). Nel caso di sincronizzazioni complesse con molteplici processi in gioco, l’aderenza a questa regola può essere complicata. I monitor sono strumenti a più alto livello che tentano di risolvere questo problema.

Utilizzo dei monitor

Il tipo monitor è un tipo di dato astratto (Abstract Data Type, ADT), ovvero un tipo di dato che incapsula dati e una serie di funzioni indipendentemente dal tipo di implementazione specifica dell`ADT. In particolare, un monitor contiene:

Un insieme di operazioni per cui è garantita l’esecuzione con mutua esclusione
Delle variabili condivise
Delle funzioni sulle variabili condivise

L’implementazione di un monitor è la seguente:


monitor monitor_name {
 /* shared variable declarations */

 function P1(...) {
 ...
 }


 function P2(...) {
 ...
 }

 .
 .
 .

 function Pn(...) {
 ...
 }

 initialization_code(...) {
 ...
 }
}

Tra le variabili condivise, è possibile definirne alcune di tipo condition, per esempio condition x, le cui uniche operazioni disponibili sono wait() e signal(). A differenza dei semafori, x.signal() non ha alcun effetto se non ci sono processi in attesa.

Supponiamo di avere un processo $Q$ in attesa e un processo $P$ che fa una chiamata signal() che risveglia $Q$. Non è possibile far eseguire entrambi i processi dentro il monitor, per cui bisogna progettare una strategia, tra le seguenti:

signal and wait: il processo $P$ lascia che $Q$ esegua e attende che esca dal monitor oppure che un’altra condizione si verifichi
signal and continue: il processo $Q$ attende che il processo $P$ esca dal monitor oppure che si verifichi un’altra condizione

Una terza soluzione potrebbe essere quella di progettare $P$ in maniera tale che esca dal monitor subito dopo che ha chiamato signal().

Implementare un monitor utilizzando i semafori

È possibile implementare un monitor utilizzando un semaforo binario mutex, inizializzato a 1. Assumiamo una strategia signal and wait, e abbiamo bisogno quindi di un semaforo aggiuntivo next inizializzato a 0, sul quale i processi possono autosospendersi con signal(). Ogni procedura esterna F viene sostituita col seguente codice:

wait(mutex);
 ...
 F
 ...
if (next_count > 0)
 signal(next);
else
 signal(mutex);

In questo modo abbiamo mutua esclusione all’interno del monitor. Per ogni variabile condition x abbiamo un semaforo x_sem e una variabile x_count entrambi inizializzati a 0. L’operazione x.wait() è implementata come segue:

x_count++;
if (next_count > 0)
 signal(next);
else
 signal(mutex);
wait(x_sem);
x_count--;

mentre la signal() viene implementata come:

if (x_count > 0) {
 next_count++;
 signal(x_sem);
 wait(next);
 next_count--;
}

È possibile implementare delle versioni meno generali e più veloci di quella proposta.

Risveglio dei processi all’interno di un monitor

Se un’operazione x.signal() viene eseguita e vari processi sono in stato di sleep, quale tra di essi va risvegliato? Una soluzione semplice potrebbe essere quella di utilizzare l’algoritmo FCFS.

Una soluzione più adeguata consiste nell’utilizzare la conditional wait. Questo costrutto viene eseguito tramite x.wait(c), dove c è un intero chiamato numero di priorità (priority number) che viene salvato assieme al numero del processo che viene sospeso. Per illustrare il meccanismo consideriamo il seguente codice

monitor ResourceAllocator
{
 boolean busy;
 condition x;

 void acquire(int time) {
 if (busy)
 x.wait(time);
 busy = true;
 }

 void release() {
 busy = false;
 x.signal();
 }

 initialization code() {
 busy = false;
 }
}

che controlla l’allocazione di una singola risorsa tra i vari processi che se la contendono. Il monitor la assegna al processo che ne ha fatto richiesta per il minor tempo possibile.

 R.acquire(t);
 ...
 access the resource;
 R.release();

Dove R è un ResourceAllocator.

Quest’implementazione presenta comunque dei problemi:

Un processo potrebbe accedere alla risorsa senza averne il permesso
Un processo potrebbe non rilasciare mai la risorsa, una volta che ci ha acceduto
Un processo potrebbe provare a rilasciare una risorsa a cui non ha mai avuto accesso
Un processo potrebbe richiedere la stessa risorsa due volte (senza rilasciarla)

È possibile spostare la logica di accesso alla risorsa all’interno del monitor ma questo significherebbe rimpiazzare lo scheduling dell’accesso con quello del monitor (invece che con quello sviluppato da noi).

Liveness

Un semplice esempio è il loop infinito. Una busy wait può rappresentare una possibilità di fallimento della liveness, se non è implementata correttamente.

Deadlock

Un caso particolare di fallimento della livenuss è il cosiddetto deadlock, che accade quando in un semaforo, due processi attendono un evento generato rispettivamente dall’altro processo. Supponiamo il seguente esempio:

 P0 P1
 wait(S); wait(Q);
 wait(Q); wait(S);
 . .
 . .
 . .
 signal(S); signal(Q);
 signal(Q); signal(S);

Se $P_0$ esegue wait(S) e $P_1$ wait(Q).

Se $P_0$ esegue wait(Q) dovrà attendere che $P_1$ faccia signal(Q)
Se $P_1$ esegue wait(S) dovrà attendere che $P_0$ faccia signal(S)

Inversione di priorità

Supponiamo di avere tre processi con priorità $L$, $M$, $H$, tali che $L < M < H$. Assumiamo che $H$ richieda una risorsa controllata da un semaforo $S$, correntemente acceduto da $L$. Supponiamo ora che $M$ diventi eseguibile e soppianti il processo $L$. Ora $H$ dovrà aspettare l’esecuzione di $M$ per poter accedere alla risorsa.

Questo problema di liveness è chiamato inversione di priorità (priority inversion) e può accadere soltanto in sistemi con più di due priorità. Tipicamente è possibile evitare questo problema implementando un protocollo di ererdità della priorità (priority-inheritance protocol). Con questo meccanismo, se un processo $H$ ad alta priorità richiede una risorsa detenuta da un processo $L$ a bassa priorità, quest’ultimo eredità la priorità del processo $H$ in maniera da prevenire altri processi con priorità media $M$ di poterla richiedere. Una volta concluso l’utilizzo, il processo a bassa priorità torna ad avere la sua priorità originale $L$

Valutazione

Riportiamo alcune semplici strategie per determinare quale strumento di sincronizzazione usare, tra quelli che abbiamo presentato in questa lezione.

Barriere di memoria e istruzioni atomiche sono tecniche di basso livello, spesso utilizzate per implementare meccanismi di sincronizzazione più sofisticati.

Se un lock non è conteso tra i processi, è preferibile una protezione CAS in quanto più veloce
Se un lock viene conteso moderatamente tra i processi, CAS risulterà più veloce della sincronizzazione tradizionale
Se un lock viene conteso spesso tra i processi, la sincronizzazione tradizionale risulterà essere più veloce di quella basata su CAS

In aggiunta, gli interi atocimi, essendo molto leggeri, sono spesso utili per aggiornare variabili come contatori condivisi. In generale i lock mutex sono semplici da utilizzare e richiedono meno overhead dei semafori, che a loro volta sono meno pesanti dei monitor.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 6.

7 Gestione della memoria

Tue, 01 Apr 2025 00:00:00 +0000

La memoria è una componente fondamentale che, assieme alla CPU, dev’essere gestita in maniera efficiente per garantire che le prestazioni di un computer non peggiorino. In questa lezione introdurremo i concetti alla base della sua progettazione logica.

7.1 Background

La memoria consiste in un grande array di byte ciascuno con il proprio indirizzo. Un programma viene caricato in memoria tramite un programma speciale chiamato program loader. La CPU legge quindi le istruzioni dalla memoria basandosi sul contatore di programma. Queste istruzioni possono causare dei load o dei store aggiuntivi da e verso la memoria.

7.2 Hardware di base

I core CPU possono accedere solamente ai registri e alla memoria centrale. Se un dato si trova in una memoria secondaria o terziaria, questo va spostato in memoria centrale per essere acceduto. I registri CPU possono essere tipicamente acceduti in un ciclo di CPU, mentre la memoria centrale, connessa tramite un bus di sistema, richiede molti cicli. Il suo accesso può generare uno stallo per l’attesa dei dati, peggiorando le prestazioni del sistema. Per ovviare al problema è possibile implementare una memoria per accesso veloce, chiamata cache, dentro il chip della CPU.

In aggiunta a ciò, è importante proteggere gli spazi di memoria dedicati ai processi kernel da parte dei processi utente, oltre che proteggere i processi utente l’uno con l’altro da accessi a zone di memoria non consentite. Per fare ciò quando un programma viene caricato, il s.o. imposta i valori di due registri, un registro base che indica l’inizio dello spazio degli indirizzi del processo, e un registro limite che indica la dimensione dello spazio degli indirizzi a cui il processo può accedere (l’indirizzo finale viene calcolato con base + limite). A ogni istruzione la CPU controlla che il processo utente acceda alla sezione di memoria a esso associata. Se ciò non avviene il s.o. emette un errore. Il s.o. esegue in modalità kernel ed è quindi libero di caricare ed eliminare i programmi dalla memoria.

7.3 Mappatura degli indirizzi

Un programma può essere caricato in qualunque parte della memoria fisica, tuttavia gli indirizzi in un codice sorgente sono tipicamente simbolici (p.e. una variabile a, con una zona di memoria ancora non specificata). La mappatura (binding) da indirizzi logici a indirizzi fisici, può avvenire nei seguenti tre modi:

Compile time binding: in questo caso il compilatore sa già dove il programma deve risiedere in memoria e può mappare direttamente gli indirizzi simbolici a indirizzi fisici (assoluti), generando codice assoluto (absolute code). Se la locazione del processo cambia sarà necessario ricompilare il programma.
Load time binding: in questo caso non è noto dove il programma risiederà in memoria, ma solamente che una volta caricato non cambierà posizione. È necessario dunque che il compilatore generi codice rilocabile (p.e. a diventa “14 byte dall’inizio del programma”). In questo caso la mappatura agli indirizzi fisici è demandata al program linker o loader (p.e. l’indirizzo rilocabile precedente diventa 74014). Se l’indirizzo di partenza cambia, è necessario eseguire nuovamente il loading del codice utente.
Execution time binding: se il processo può essere spostato in memoria durante la sua esecuzione, la mappatura deve avvenire a tempo di esecuzione. Il linker o il loader generano indirizzi simbolici (chiamati virtuali) e un hardware speciale si occupa della mappatura a indirizzi fisici (lo vedremo a breve). La maggior parte dei sistemi operativi utilizza questo metodo.

7.4 Spazio degli indirizzi logico e fisico

Ogni programma e la CPU operano generalmente con indirizzi logici, mentre la memoria opera con indirizzo fisici. In caso di mappatura a compile e load time gli indirizzi logici e fisici coincidono. Con la mappatura a execution time l’indirizzo logico, chiamato indirizzo virtuale (utilizzeremo tuttavia entrambi i termini logico e virtuale allo stesso modo), va invece convertito in indirizzo fisico tramite dell’hardware specializzato, l’unità di gestione della memoria (memory-management unit, MMU). Ogni volta che la CPU effettua una store o una load sulla memoria, l’indirizzo virtuale viene quindi convertito dalla MMU in indirizzo fisico e viceversa. Introduciamo un semplice schema di mappatura che generalizza quello del registro base. Tale registro viene chiamato, in questo contesto, registro di rilocazione (relocation register). Questo valore è aggiunto a ogni indirizzo da un processo utente nel momento in cui l’indirizzo è inviato in memoria. Se il registro rilocabile è 14000, allora 0 sarà mappato a 14000 e 346 a 14346. Sottolineiamo di nuovo che il programma non ha accesso all’indirizzo fisico, solo a quello rilocabile.

7.5 Linking e Loading

Un programma è tipicamente composto da librerie di routine. Le librerie sono simili a programmi e hanno il loro spazio degli indirizzi personale. Per l’integrazione delle librerie nell’eseguibile è necessario rintracciare le librerie e rimappare tutti i loro indirizzi perché non ci siano overlap. Per fare ciò, esistono tre diverse modalità: static linking, dynamic linking e dynamic loading.

7.5.1 Static Linking

In questo caso, il linker tratta le librerie come moduli oggetto e le combina all’interno dell’eseguibile del programma, a compile time. L’eseguibile contiene quindi tutto ciò che serve per eseguire ma incrementa in dimensioni poiché porta con sé anche le librerie, che vengono chiamate librerie statiche (static libraries). In aggiunta, le librerie vengono caricate in memoria, una volta per programma, anche se sono già presenti, occupando maggiore spazio. In Windows le librerie statiche vengono definite con l’estensione .lib, in Linux con .a.

7.5.2 Dynamic Linking

In questo caso, il linking delle librerie avviene a load time. In particolare, il loader chiama il linker che si occupa di controllare se le librerie richieste sono già in memoria, altrimenti le carica, aggiornando gli indirizzi. Le librerie possono essere quindi condivise tra vari programmi e per tale motivo si chiamano anche librerie condivise (shared libraries). Inoltre, col dynamic linking è possibile tenere in memoria secondaria degli eseguibili più piccoli, ed è possibile aggiornare le librerie condivise senza dover ricompilare gli altri programmi. Sono molto utilizzate nei sistemi Windows, dove vengono chiamate dinamically linked libraries (.dll), e Linux (shared object, .so). Per evitare che vengano inavvertitamente utilizzate delle librerie di una versione incompatibile, viene solitamente incluso un numero di versione che controllato a linking time. Il dynamic linking richiede l’intervento del s.o. per permettere la condivisione di librerie a più processi.

7.5.3 Dynamic Loading

In questo caso il caricamento della libreria avviene a run time, al momento del suo effettivo utilizzo, tramite la chiamata di una funzione nel codice dell’eseguibile (p.e. load_library(<nome libreria>)). Le routine vengono salvate in uno speciale formato rilocabile e quando un’altra routine viene chiamata, il chiamante controlla se il chiamato è già presente in memoria. Se non lo trova, il loader lo carica dalla memoria secondaria, aggiorna la tabella degli indirizzi del programma e passa il controllo alla routine chiamata. Le routine posso anche essere rilasciate, liberando così memoria. Questo metodo è efficace nel caso di routine molto grandi che vengono chiamate poco frequentemente, come ad esempio quelle per la gestione degli errori. Il loading dinamico non richiede speciale supporto da parte del s.o. ed è di responsabilità dello sviluppatore. Il s.o. può tuttavia fornire delle routine di libreria per implementare il loading dinamico.

7.6 Allocazione contigua della memoria

La memoria centrale deve accomodare sia il s.o. che i vari processi utente. Abbiamo quindi bisogno di allocare lo spazio nella migliore maniera possibile. La memoria viene divisa generalmente in due partizioni: una per il s.o. e una per i processi utente. È possibile allocare la memoria s.o. negli indirizzi più bassi o più alti della memoria, tuttavia molti s.o. (tra cui Windows e Linux) utilizzano gli indirizzi alti. Nell’allocazione di memoria contigua ogni processo utente viene allocato in una singola sezione di memoria contigua a quella del processo successivo.

7.7 Protezione della memoria

Possiamo prevenire che un processo acceda alla memoria di un altro processo combinando la tecnica del registro base e del registro di rilocazione precedentemente visto. Dal momento che gli indirizzi rilocabili vanno da 0 (incluso) al valore specificato dal registro di rilocazione limite (escluso), quando una CPU esegue un’istruzione di accesso alla memoria è necessario solamente che controlli che <indirizzo rilocabile> < <registro limite>. In tal caso, la CPU computerà <indirizzo fisico> = <registro base> + <indirizzo rilocabile> per ottenere l’indirizzo fisico.

7.8 Allocazione della memoria

Tra le sfide nella gestione dei processi in memoria, troviamo il problema dell’allocazione dinamica di spazio. Uno dei metodi più semplici per allocazione della memoria consiste nell’allocare, per ciascun processo, una partizione di memoria di dimensione variabile. Inizialmente tutta la memoria è disponibile ed è considerata un buco (hole). Progredendo col caricamento e la terminazione dei processi, la memoria conterrà vari buchi inutilizzati. Nel momento in cui un processo entra in memoria il s.o. tiene in conto dei requisiti di memoria necessari. Se non c’è memoria sufficiente è possibile rifiutare il processo o piazzarlo in una coda di attesa. Se invece un processo è di dimensione minore rispetto a un buco contenuto nell’insieme dei buchi, può venire piazzato lì. In tal caso, se c’è molto spazio all’interno del buco, solo una parte viene allocata al processo e la rimanente ritorna nell’insieme dei buchi. Quando un processo termina lasciando un buco, se questo è adiacente a un altro buco entrambi vengono uniti in un buco soltanto. La scelta tra i buchi disponibili in cui allocare un nuovo processo è basata su una strategia di allocazione. Tra le più note troviamo:

First-fit: alloca il primo buco che è grande abbastanza per contenere il processo. La ricerca può cominciare all’inizio dell’insieme dei buchi o nella locazione dove la ricerca si era precedentemente conclusa. La ricerca si ferma una volta trovato il buco.
Best-fit: alloca il buco più piccolo che può contenere il processo. La ricerca richiede di controllare tutti i buchi disponibili (se non è ordinata per dimensione).
Worst-fit: alloca il buco più grande che può contenere il processo. La ricerca richiede di controllare tutti i buchi disponibili (se non è ordinata per dimensione). Questa strategia lascia più spazio rimanente nel buco e può essere più utile della strategia best-fit.

Le simulazioni dimostrano che first-fit e best-fit sono i migliori in termini di utilizzo della memoria e del tempo. Tra questi due first-fit è il più veloce in termini di tempo, mentre non c’è una differenza sostanziale in termini di memoria occupata.

7.9 Frammentazione

Con gli algoritmi first-fit e best-fit, l’allocazione e la rimozione dei processi può generare problemi di frammentazione. Esistono due tipologie di frammentazione:

Frammentazione esterna: in seguito all’allocazione e rimozione dei processi si creano molti piccoli buchi all’interno della memoria. Questo fenomeno accade quando ci sarebbe memoria sufficiente per ospitare un nuovo processo ma questa è frammentata in molteplici buchi non contigui. Analisi statistiche sull’algoritmo first-fit confermano che allocando $N$ blocchi, altri $0.5N$ blocchi vengono persi per via della frammentazione ($50$-percent rule). Una soluzione al problema è il compattamento (compaction) per cui la memoria viene riorganizzata per accostare i buchi e unirli insieme. Questa metodologia non è possibile se la rilocazione è stata fatta a compile o load time. Bisogna inoltre calcolare il costo della rilocazione, quando questa è possibile. La strategia più semplice, ma anche costosa, è quella di spostare tutti i processi da una parte e i buchi dall’altra. È anche possibile permettere che lo spazio degli indirizzi di un processo non sia contiguo. Questa strategia è chiamata paging ed è la più comune nei s.o.
Frammentazione interna: supponiamo di avere un processo da $18,462$ bytes allocato in un buco da $18,464$ bytes. Il peso della struttura usata per tracciare i due byte rimanenti sarebbe maggiore dei due byte stessi comportando uno spreco di memoria. Per ovviare a questa situazione è possibile allocare un blocco fisso di memoria, maggiore della memoria richiesta dal processo. La rimanenza tra la memoria del blocco e quella effettivamente occupata dal processo viene chiamata frammentazione interna.

7.10 Paging

Immaginate di avere una memoria da 1GiB indicizzabile a livello di byte. Se vogliamo mappare ogni byte abbiamo in totale $1Gi = 2^{30}$ indirizzi da gestire. La mappatura richiede quindi che un indice sia lungo 30 bit, ma dal momento che lavoriamo a livello di byte dobbiamo utilizzare 32 bit (4B). L’indicizzazione dei byte pesa quindi $4B \cdot 2^{30} = 2^{32}B = 4GiB$, molto più della memoria stessa! Questo approccio di mappatura è dunque infattibile, e per ovviare al problema utilizziamo il paging.

Il paging è una tecnica che consiste nell’assegnare un indirizzo a un insieme di zone di memoria indicizzabili (tipicamente i byte), contigue tra loro. Gli insieme così indicizzati, di dimensione fissa, vengono chiamati frame nella memoria fisica, e pagine (pages) in quella logica. Lo spazio logico degli indirizzi di un programma viene quindi diviso in pagine, e quando un processo viene eseguito, le sue pagine vengono caricate in memoria. La corrispondenza tra frame e pagine è arbitraria. In altre parole, una pagina con indirizzo 3 può essere mappata nel frame 9.

Il paging permette anche di caricare solo una parte delle pagine programma in maniera da ottimizzare l’utilizzo della memoria fisica. Inoltre, l’idea di separare la memoria fisica da quella logica ci permette di avere indirizzi logici di, per esempio, $64$ bit senza avere una memoria fisica da $2^{64}$ bit.

Ogni indirizzo generato dalla CPU viene diviso in due parti:

Numero di pagina ($p$): è usato come un indice dentro una tabella di pagine, relativa a un singolo processo e contenente l’indirizzo fisico di ogni frame.
Offset di pagina ($d$): è l’offset utilizzato per riferirsi alla locazione esatta nel frame.

L’MMU esegue i seguenti step per tradurre un indirizzo logico in quello fisico:

Estrarre il numero di pagina $p$ e utilizzarlo per cercare nella tabella delle pagine.
Estrarre il corrispondente numero di frame $f$ dalla tabella delle pagine.
Rimpiazzare il numero di pagina $p$ nell’indirizzo logico col numero di frame $f$.
Aggiungere l’offset $d$ al numero di frame $f$ per ottenere l’indirizzo fisico.

La dimensione di una pagina è definita a livello hardware ed è una potenza di $2$ (tipicamente tra $4$KB e $1$GB). In questo modo, se la dimensione della pagina è $2^n$ e la dimensione dello spazio logico è $2^m$ ($m > n$), allora un indirizzo logico contiene $m$ bit, gli $n$ bit meno significativi indicano l’offset di pagina e gli $m - n$ bit più significativi sono riservati al numero di pagina.

Il paging è un sistema di rilocazione simile a quelli visti in precedenza. Non crea frammentazione esterna poiché la memoria fisica viene partizionata in anticipo, tuttavia può creare frammentazione interna, poiché un processo potrebbe non occupare completamente l’ultima pagina a esso allocata. Nel peggiore dei casi potremmo avere l’allocazione di un solo byte nell’ultima pagina risultando in una frammentazione interna di quasi un intero frame. Possiamo stimare una frammentazione interna media di mezza pagina, quindi è bene avere una dimensione di pagina piccola, tuttavia avere molte pagine implica un overhead nella gestione delle struttura delle entry di pagina. Inoltre, dal punto di vista del I/O su disco (memoria secondaria) è meglio avere grandi quantità di dati da trasferire. In generale le pagine oggi sono di $4$K o $8$K. Molti s.o. supportano più dimensioni di pagina.

Un programma, prima dell’esecuzione esprime la sua dimensione in pagine. Se richiede $n$ pagine, è necessario disporre di $n$ frame per poterlo allocare. La mappatura è gestita dal s.o., che tiene traccia dei frame liberi attraverso una tabella dei frame (frame table). Questa struttura indica quali frame sono liberi, quali sono occupati e da che processi sono occupati.

7.11 Supporto hardware

Ogni PCB del processo contiene un puntatore alla tabella delle pagine a esso associate, e questa tabella viene caricata dalla CPU ogni volta che un processo entra in esecuzione. Vediamo due modi per fare l’implementazione hardware della tabella delle pagine:

Insieme di registri CPU dedicati: In questo caso viene utilizzato un set di $N$ registri specializzati cosicché il registro $p$ contiene l’indirizzo del frame associato alla pagina $p$ del processo in CPU. Questa implementazione è utile per fare velocemente traduzioni pagina-frame, ma aumenta i tempi di context switch e non può essere utilizzata in caso di page table grandi.
Puntatore in memoria: nella maggior parte dei s.o. moderni, è necessario salvare la page table in memoria e utilizzare un singolo registro specializzato, il Page-Table Base Register, PTBR, che contiene l’indirizzo iniziale della page table del processo. Cambiare la page table richiede solo di cambiare il valore di questo registro riducendo sostanzialmente il tempo di context switch e l’utilizzo di page table più grandi.

7.11.1 buffer di traduzione look-aside

Se salviamo la tabella delle pagine in memoria risparmiamo tempo nel context switch ma l’accesso alla tabella situata nella memoria peggiora le performance poiché dobbiamo accedere alla PTBR ricavare l’indirizzo e accedere poi alla pagina cercata. È possibile implementare una piccola e veloce cache di ricerca chiamata buffer di traduzione Look-aside (Translation Look-aside Buffer, TLB). Ogni entry del TLB consiste in una chiave e un valore. Quando arriva un oggetto, questo viene confrontato con tutte le chiavi finché non avviene un match e viene ritornato il corrispondente valore. Il TLB è piccolo in dimensioni, da $32$ a $1024$ entry. Alcune CPU hanno una TLB per le istruzioni e una per i dati.

Relativamente al paging, una TLB contiene solamente una piccola parte delle entry della tabella di pagine. Quando un’indirizzo logico viene generato, l’MMU controlla se il numero di pagina (la chiave) è nella TLB e ritorna immediatamente il rispettivo numero di frame (il valore) a esso associato. Se il numero di pagina non è presente si verifica un TLB miss. In questo caso, viene eseguita la traduzione da pagina a frame e poi la mappatura viene salvata nella TLB. Se la TLB è piena, è necessario eliminare una entry. Varie strategie possono essere applicate, dal round-robin a politiche che selezionano la pagina recentemente meno utilizzata (Least Recently Used, LRU). Alcune entry possono essere fissate (wired down), ad esempio le entry relative a codice kernel fondamentale.

Alcuni TLB salvano anche un identificatore dello spazio degli indirizzi (Adress-Space Identifier, ASID) che determina l’identità del processo per garantire protezione. Quando un TLB prova a risolvere un numero di pagina virtuale, controlla che l’ASID della mappatura corrisponda a quello del processo, in caso contrario restituisce un TLB miss. Senza ASID, ogni volta che una nuova tabella delle pagine viene selezionata (p.e. durante un context switch) il TLB deve assicurarsi che il suo contenuto venga resettato (flushed), per garantire che la precedente tabella non crei conflitti puntando a indirizzi sbagliati.

Per misurare le prestazioni di una TLB è possibile calcolare la, hit ratio, ovvero la percentuale di volte in cui l’informazione richiesta si trova nella TLB. Per calcolare il tempo di accesso effettivo in memoria si può utilizzare la seguente formula:

$$ \begin{align} & \text{effective access time} = \underbrace{\text{hit ratio} \times \text{page access time}}_{TLB\ hit} + \nonumber\\ & + (1 - \text{hit ratio}) \times \underbrace{(\text{page table access time} + \text{page access time})}_{TLB\ miss} \end{align} $$

Con $page\ table\ access\ time = page\ access\ time$. In altre parole, se l’entry si trova nella TLB dovrò accedere solamente alla pagina, in caso contrario bisogna consultare la memoria anche per accedere alla page table. In questo esempio, assumiamo che sia richiesto solo un accesso in caso di TLB miss e che i tempi di accesso al TLB siano trascurabili.

7.12 Protezione

È possibile implementare degli approcci di sicurezza per evitare che alcune pagine siano read-only o read-write, o temporaneamente non disponibili (p.e. per swapping del frame in memoria secondaria), e così via. Tipicamente vengono associati dei bit di validità alla pagina, che indicano quali operazioni sono disponibili.

7.13 Pagine condivise

Uno dei vantaggi del paging è la possibilità di condividere pagine tra processi. Supponiamo ad esempio il caso di alcuni processi che utilizzano la stessa libreria standard, con cui è possibile risparmiare spazio creando alcune tabelle di pagine che si riferiscono alla stessa zona di memoria fisica contenente la libreria. Il codice in oggetto è chiamato reentrant code e dev’essere non modificabile, in maniera tale da garantire l’integrità dei suoi dati.

7.14 Struttura di una tabella di pagine

In questa sezione esploriamo tecniche comuni per strutturare una tabella di pagine.

7.14.1 Paging gerarchico

Con i sistemi moderni, una tabella di pagine può diventare molto grande e occupare molto spazio in memoria. Per esempio, su un sistema a $32$-bit con pagine di dimensione $4$K ($2^{12}$) una tabella delle pagine consisterebbe di $2^{32} / 2^{12}$ entry. Se la dimensione di un’entry è, ad esempio di 4 byte, consumeremmo 4MB di memoria a processo solo per la tabella delle pagine.

È possibile ovviare al problema inserendo una struttura di paging gerarchica in cui anche la tabella delle pagine viene paginata. Ad esempio nel precedente sistema, se associamo $20$ bit al numero di pagina e $12$ bit all’offset, potremmo “paginare” la tabella, dividendo i $20$ bit in $10$ per un primo livello e $10$ per un secondo livello di paging. Il livello più interno si riferirebbe sempre al numero di pagina, mentre quello esterno sarebbe relativo a una tabella delle pagine esterna, che indicizza la tabella delle pagine interna.

Il processo può essere esteso a più livell di gerarchia, per caricare meno dati in memoria. Questa strategia richiede tuttavia più accessi alla memoria, uno per livello, peggiorando le prestazioni in termini di efficienza computazionale.

7.14.2 Tabelle hash di pagine

Un approccio per gestire gli spazi di indirizzi maggiori di 32 bit è quello di usare una tabella hash di pagine (hashed page table) con il valore di hash corrispondente al numero virtuale di pagina. Ogni entry della tabella contiene una lista concatenata. Ogni elemento consiste in tre campi:

Il numero di pagina virtuale $p$
Il valore del frame mappato $s$
Un puntatore all’elemento successivo nella lista concatenata

$p$ viene convertito nel valore hash e l’entry corrispondente viene cercata nella tabella. $p$ viene quindi confrontato con gli elementi della lista per trovare il frame $s$ corrispondente.

7.14.3 Tabella di pagine invertita

Tutte le tabelle di pagine puntano ai frame della memoria fisica. Per risparmiare spazio possiamo salvarci una tabella invertita che, a ogni frame, mappa la pagina virtuale a esso associato. Per garantire protezione da accessi non voluti, è necessario salvare anche il PID del processo associato alle pagine virtuali. In questo modo è possibile salvarsi un’unica tabella anziché una tabella per processo, salvando molta memoria.

Questo metodo è costoso in termini di ricerca, poiché per fare una mappatura da pagina a frame bisogna potenzialmente scorrere tutti i frame uno a uno finché non viene trovato il riferimento. Per accelerare il processo è possibile utilizzare una tabella hash. Inoltre, un grosso svantaggio è costituito dal fatto che è possibile salvare solo un riferimento per frame e quindi un frame non può essere condiviso tra processi (sono necessarie tecniche alternative per farlo).

7.15 Swapping

Lo swapping è una tecnica per ampliare la spazio degli indirizzi fisici, che consiste nello spostare (swapping) processi, o porzioni di un processo in un backing store temporaneo che risiede tipicamente nella memoria secondaria.

7.15.1 Standard swapping

Questa tecnica prevede di spostare un processo intero tra la memoria e il backing store. Il vantaggio principale consiste nel permettere alla memoria fisica di essere sovrascritta permettendo di gestire più processi. I processi in attesa sono buoni candidati per lo swapping.

7.15.2 Swapping con paging

Il swapping standard richiede molto tempo per lo spostamento dei processi ed è stato quasi sempre sostituito con il swapping di una parte delle pagine di un processo. Il termine swapping si riferisce allo swapping standard mentre il termine paging allo swapping con le pagine. Un’operazione di page out sposta una pagina dalla memoria al backing store, mentre un’operazione di page in fa il contrario.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 9.

8 Gestione della memoria virtuale

Tue, 08 Apr 2025 00:00:00 +0000

In questa lezione approfondiremo i concetti sottostanti la memoria virtuale, la sua implementazione e alcune considerazioni sulla sua efficenza computazionale

8.1 Background

Ci sono varie casistiche da considerare per poter risparmiare memoria:

Durante la sua esecuzione, un programma non utilizza tipicamente tutto il codice della sua implementazione. Le routine di errore, per esempio, vengono chiamate solo all’occorrenza.
Alcune strutture dati (p.e. array) possono venire allocate con maggiore memoria di quella effettivamente richiesta

Per tali motivi, è utile caricare solo parte di un programma in memoria, utilizzando una memoria virtuale. I vantaggi sono:

Un programma può accedere a uno spazio virtuale molto più grande di quello fisico
Molti programmi possono eseguiti contemporaneamente
Sono necessarie meno operazioni di I/O per lo swapping completo dei programmi
Il programmatore non si deve preoccupare di gestire la memoria permettendogli di sviluppare codice più facilmente

Nella gestione della memoria virtuale, possiamo allocare negli indirizzi iniziali le istruzioni del programma, seguite dai dati e dall’heap dinamico. Negli indirizzi finali, in coda allo spazio degli indirizzi allochiamo lo stack, lasciando così un buco intermedio tra stack e heap che può essere utilizzato per estendere queste strutture o caricare le librerie dinamiche.

La memoria virtuale ci permette anche di:

Condividere librerie di sistema
Condividere codice in comune (p.e. a seguito di una fork)
Avviare una comunicazione tramite memoria condivisa

8.2 Paging su richiesta

Come detto, è possibile caricare solo parzialmente le parti di un programma, posticipando il caricamento di pagine specifiche solamente quando queste sono richieste dal processo per continuare a eseguire. Questa tecnica si chiama paging su richiesta (demand paging).

8.2.1 Concetti base

Il paging su richiesta necessita di un meccanismo per indicare quali pagine nella tabella delle pagine sono state caricate in memoria. È possibile, a tal proposito, utilizzare un bit di validità. Quando il bit è impostato a true, la pagina è valida, altrimenti la pagina non è valida oppure non è stata caricata in memoria centrale. Nel caso si provi ad accedere una pagina con bit a false, viene emesso un page fault che viene catturato dal s.o. La procedura di gestione dell’errore è la seguente:

Viene controllata una tabella interna al processo per vedere se la pagina non è valida
Se la pagina non è valida il processo termina, se è valida la pagina viene caricata
Viene cercato un frame libero per l’allocazione della pagina
La pagina viene letta dalla memoria secondaria e allocata nel nuovo frame
Viene aggiornata la tabella delle pagine per indicare che la pagina è ora valida
L’esecuzione del processo riprende

Nel caso estremo, un processo può essere inizializzato con zero pagine in memoria (pure demand paging).

Può accadere che un processo richieda molte pagine il cui bit è impostato a false una di seguito all’altra comportando un peggioramento delle performance inaccettabile. Quest’eventualità è molto rara poiché i programmi tendono ad avere una località dei riferimenti, per cui molti accessi consecutivi avvengono spesso in locazioni vicine tra loro.

Quando un processo tenta di accedere a una pagina non caricata in memoria, si interrompe e riprende l’esecuzione al suo caricamento. Questo può comportare la ripetizione dell’istruzione che stava eseguendo. Per esempio, nel caso di una operazione di somma:

Gli addendi A e B vengono letti
Il risultato A + B viene computato
Il risultato viene salvato in C

Nel caso in cui C corrispondesse a una locazione di memoria in una pagina invalida, il processo va in interruzione per caricare la pagina corrispondente, e alla sua ripresa deve ricomputare la somma. Nel caso di istruzioni che implicano lo spostamento di grossi moli di dati, questo può peggiorare le performance. Esistono varie soluzioni a questo problema.

8.2.2 Lista di frame liberi

Molti sistemi utilizzano una lista di frame liberi (free-frame list) per trovare subito un frame disponibile a ospitare una pagina dopo un page fault. I s.o. allocano tipicamente frame utilizzando una tecnica chiamata zero-fill on demand che resetta il frame prima di eseguirne l’allocazione, per evitare problemi di sicurezza dovuti a un potenziale leakage di dati.

8.2.3 Performance del paging su richiesta

Calcoliamo ora il tempo effettivo di accesso (effective access time) con il paging su richiesta. Sia $p$ la probabilità di page fault ($0 \le p \le 1$) ed $ma$ il tempo di accesso alla memoria. Il tempo effettivo di accesso è

$$ \text{effective access time} = (1 - p) \times ma + p \times \text{page fault time} $$

Il tempo di page fault (page fault time) è il più complicato da stimare, ed è composto da tre operazioni principali:

Servire l’interrupt del page fault
Leggere la pagina
Riprendere l’esecuzione del processo

8.3 Copy-on-write

Quando un processo genitore chiama la fork() e genera un processo figlio, questo ultimo riceve, di norma, anche una copia dello spazio degli indirizzi su cui operare. Tuttavia considerando che molti figli invocano exec() immediatamente dopo la loro creazione, è possibile minimizzare il consumo di memoria utilizzando la tecnica di copy-on-write. In particolare, tutte le pagine condivise vengono etichettate come copy-on-write e vengono duplicate solamente all’occorrenza, quando uno dei due processi ci esegue un’operazione di scrittura. Solamente le pagine modificabili vengono etichettate, quelle non-modificabili (p.e. quelle contenenti il codice eseguibile) no.

8.4 Sostituzione delle pagine

Col paging su richiesta è possibile eseguire molti processi anche se il loro spazio degli indirizzi complessivo fosse più grande della memoria disponibile, poiché solamente una parte delle pagine viene caricata.

Può accadere tuttavia che i processi richiedano contemporaneamente molte pagine in memoria e che lo spazio fisico sia effettivamente insufficiente. In questo caso, incorriamo nel sovrallocamento della memoria. Nel momento in cui una nuova pagina non può essere allocata, possiamo terminare il processo che l’ha richiesta. Questa soluzione è tuttavia non ottimale, ed è meglio fare swapping di altre pagine.

8.4.1 Sostituzione delle pagine standard

Quando un processo registra un page fault, l’algoritmo standard per la sostituzione di pagine funziona nel seguente modo:

Trova la locazione della pagina da caricare nella memoria secondaria.
Trova un frame libero.
1. Se c’è un frame libero, usalo.
2. Se non c’è, usa un algoritmo di sostituzione pagina per selezionare un victim frame.
3. Salva il victim frame nella memoria secondaria (se necessario), cambia la pagina e il frame.
Carica la pagina desiderata nel frame liberato, aggiorna le tabelle delle pagine e dei frame.
Continua a eseguire il processo dal momento del page fault.

In caso non ci siano frame liberi, sono richiesti normalmente due trasferimenti, uno per la pagina in entrata e uno per la pagina in uscita. Si può ridurre l’overhead utilizzando un modify bit (o dirty bit), che specifica se il victim frame è stato modificato e va quindi salvato in memoria o può essere semplicemente sovrascritto.

All’aumentare del numero di frame disponibili il numero di page fault decrementa, assumendo un andamento simil-esponenziale.

Per implementare correttamente il paging su richiesta è necessario trovare un algoritmo di sostituzione pagine e uno di allocazione dei frame.

8.4.2 Sostituzione pagine FIFO

L’algoritmo più semplice è il First-In, First-Out (FIFO) che seleziona la pagina più vecchia in memoria per la sostituzione. Non serve salvare il tempo in cui le pagine sono state allocate, basta utilizzare una coda FIFO. Se una pagina in uso viene sostituita, questa verrà riallocata in memoria al prossimo page fault, garantendo comunque la correttezza dell’algoritmo.

8.4.2.1 Anomalia di Belady

L’algoritmo FIFO può incorrere in un particolare fenomeno noto come anomalia di Belady, per il quale con l’aumentare del numero di frame disponibili, aumenta il numero di page fault. Consideriamo la sequenza 1, 2, 3, 4, 1, 2, 5, 1, 2, 3, 4, 5. Simulando l’algoritmo FIFO su una memoria fisica da 3 frame otteniamo 9 page fault, mentre con una memoria da 4 frame otteniamo 10 page fault!

8.4.3 Sostituzione pagine ottimale

Esiste un algoritmo ottimale di sostituzione pagine, chiamato OPT o MIN. La regola è semplice e consiste nel sostituire la pagina che non verrà utilizzata per il periodo più lungo di tempo. Sfortunatamente l’algoritmo è difficile da implementare perché richiede di stimare l’utilizzo delle pagine nel futuro. Per tale motivo viene utilizzato solo come riferimento. Questo algoritmo non soffre dell’anomalia di Belady.

8.4.4 Sostituzione pagine LRU

Un’altro algoritmo di sostituzione pagine è il cosiddetto Least Recently Used (LRU). LRU associa a ogni pagina il tempo in cui è stata utilizzata l’ultima volta e, quando è necessaria una sostituzione, viene eliminata la pagina utilizzata meno recentemente.

È un algoritmo comunemente utilizzato. Il problema principale è l’implementazione del meccanismo di memoria, che viene generalmente eseguito in due modi:

Contatori: Associamo a ogni entry della tabella delle pagine un tempo di utilizzo e aggiungiamo alla CPU un clock logico o un contatore. Ogni volta che avviene l’accesso a una pagina, il suo tempo viene registrato nella entry di riferimento. In caso di sostituzione, la pagina con il tempo minore viene scelta per la sostituzione. Questo metodo richiede lo scorrimento delle pagine per la ricerca della pagina LRU e un’operazione di scrittura per l’aggiornamento delle pagine a ogni accesso in memoria.
Stack: Un altro approccio è uello di utilizzare una pila di numeri di pagina. Quando una pagina viene acceduta, viene messa sopra la pila. In questa maniera le pagine utilizzate più recentemente sono mantenute sopra lo stack. La struttura dati da utilizzare è una lista doppiamente concatenata con un puntatore alla testa e alla coda. Questo approccio è particolarmente vantaggioso.

Anche questo algoritmo non soffre dell’anomalia di Belady. Sia l’algoritmo ottimale che questo algoritmo vengono chiamati algoritmi stack poiché si può dimostrare che l’insieme di pagine in memoria su $n$ frame è sempre il sottoinsieme di pagine che sarebbe in memoria con $n + 1$ frame. Per la sostituzione LRU, l’insieme di pagine in memoria consisterebbe nelle $n$ pagine utilizzate più recentemente.

8.4.4.1 Sostituzione pagine LRU approssimata

Non tutti i sistemi forniscono hardware sufficiente per supportare LRU. Molti sistemi forniscono qualche aiuto, nella forma di bit di riferimento (reference bit). Il bit di riferimento per una pagina è impostato dall’hardware a $1$ ogni volta che la pagina viene acceduta. È possibile esaminare e selezionare la pagina da sostituire tra quelle che non sono state utilizzate, anche se non conosciamo l’ordine di utilizzo.

È possibile estendere l’algoritmo includendo diversi bit di riferimento. A intervalli regolari (p.e. ogni $100$ millisecondi), avviene un interrupt che trasferisce il controllo al s.o. che si occupa di fare lo shift dei bit, scartando quello meno significativo e impostando il bit più significativo a $1$ nel caso la pagina sia stata utilizzata, durante l’intervallo precedente. La sequenza di bit così formata è un intero (p.e. $10111111$, con $8$ bit, indica che la pagina non è stata acceduta nel penultimo intervallo soltanto). Possiamo quindi selezionare tutte le pagine corrispondenti all’intero minimo e rimuoverle tutte oppure utilizzare un metodo FIFO per sceglierne una soltanto.

L’algoritmo LRU con un solo bit di riferimento viene chiamato algoritmo di sostituzione pagine con seconda possibilità (second-chance page-replacement algorithm). È possibile utilizzare il bit di riferimento assieme a quello di modifica per ottenere un’analisi più completa dell’utilizzo della pagina:

(0, 0) pagina non recentemente usata, né modifica. Rappresenta il candidato migliore per la sostituzione
(0, 1) pagina non recentemente usata, ma modificata. La sua sostituzione comporta una scrittura in memoria secondaria
(1, 0) pagina recentemente usata, ma non modificata. Probabilmente verrà usata di nuovo
(1, 1) pagina recentemente usata e modificata. Verrà probabilmente riusata e in ogni caso dovrebbe venire scritta nella memoria secondaria

8.4.5 Sostituzione pagine basata su conteggio

Ci sono altri algoritmi che possono essere usati per la sostituzione delle pagine. Per esempio possiamo tenere un riferimento al numero di volte in cui una pagina è stata acceduta.

8.4.6 Algoritmi di buffering di pagina

È possibile implementare dei buffer di frame liberi, in maniera tale che quando accade un page fault, la pagina richiesta possa essere caricata subito nel buffer, mentre il victim frame viene liberato.

8.5 Allocazione dei frame

Passiamo ora al problema dell’allocazione dei frame ai vari processi. In particolare, ci chiediamo quanti frame dobbiamo assegnare a ciascun processo.

8.5.1 Numero di frame minimo

È importante allocare un numero minimo di frame per processo. Le motivazioni di questa scelta sono due:

Col diminuire di frame disponibili per un processo, i suoi page fault aumentano, diminuendo le prestazioni.
Quando avviene un page fault prima che un’istruzione sia completata, l’istruzione va ri-eseguita da capo.

Solitamente un’architettura stabilisce il numero minimo di frame e imposta il numero massimo con il numero di frame totali nella memoria fisica.

8.5.2 Algoritmi di allocazione

La maniera più semplice per allocare $m$ frame a $n$ processi è di dare a ciascuno un ammontare uguale di $m/n$ frame. Per esempio, con $93$ frame e $5$ processi daremmo $18$ frame a ciascuno, tenendo i rimanenti $3$ come buffer. Questo schema è chiamato allocazione uniforme.

Un’alternativa è quella di riconoscere che i vari processi richiederanno un differente ammontare di memoria. Se abbiamo un sistema con frame a dimensione $s$ e $n$ processi $P_1, \dots, P_n$ che pesano $s_1, \dots, s_n$, possiamo calcolare

$$ S = \sum_{i = 1}^n s_i $$

e calcolare quanti frame allocare a ogni processo utilizzando la seguente formula

$$ a_i = s_i / S \times m. $$

Dobbiamo poi regolare il numero affinché sia un intero maggiore del numero minimo di frame e minore di $m$. Questo algoritmo si chiama di allocazione proporzionale.

Lo svantaggio di questo metodo è che non fa distinzioni tra processi a bassa e alta priorità. Questi ultimi potrebbero avere delle maggiori esigenze in termini di memoria per garantire la loro esecuzione in tempi stretti. È possibile quindi calcolare lo spazio di allocazione anche in base alla priorità del processo.

8.5.3 Allocazione globale vs locale

Possiamo classifiare gli algoritmi di sostituzione pagine in due macro categorie:

Rimpiazzamento globale: un processo può selezionare un qualunque frame di sostituzione, anche tra i frame posseduti da altri processi. È utile per esempio per permettere a processi ad alta priorità di selezionare all’occorrenza frame da processi a bassa priorità. Il problema principale è che il comportamento di paging di ogni processo varia e non è quindi facile prevedere quali pagine selezionare. In ogni caso, il rimpiazzamento globale è la scelta più comunemente adottata.
Rimpiazzamento locale: un processo può selezionare un frame di sostituzione solo tra quelli a esso allocati. Il problema principale è che il processo non può accedere a frame di altri processi che potrebbe essere sottoutilizzati.

È possibile implementare il rimpiazzamento globale utilizzando una lista di frame liberi che soddisfi i page fault dei processi. La lista viene utilizzata fino a che la sua dimensione scende fino a una certa soglia minima, positiva. Raggiunta la soglia i processi smettono di richiedere frame liberi e avviano l’algoritmo di sostituzione pagine. In questo modo, vengono conservati dei frame liberi utilizzabili per nuove richieste (p.e. un nuovo processo viene caricato in memoria). Raggiunta la soglia minima, inoltre, il kernel avvia un processo reaper, che inizia a reclamare le pagine assegnate agli altri processi (kernel escluso) utilizzando un algoritmo di rimpiazzamento pagina. Il reaper non utilizza effettivamente i frame, ma li libera soltanto, incrementando la lista di frame liberi. L’operazione continua finché non viene raggiunta una soglia superiore e i processi possono tornare a richiedere frame dalla lista di frame liberi.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 10.

9 Memoria di massa

Wed, 09 Apr 2025 00:00:00 +0000

In questa lezione vedremo i meccanismi di base e il modo in cui i s.o. traducono le loro proprietà fisiche in memoria logica tramite la mappatura degli indirizzi.

9.1 Struttura dei dispositivi di memorizzazione

I dischi magnetici (o rigidi) e i dispositivi NVM cosituiscono i supporti fondamentali di memoria secondaria dei computer. Di seguito riportiamo le loro caratteristiche principali.

9.1.1 Dischi rigidi

I dischi rigidi sono costituiti da piatti che hanno una forma piana e rotonda, come quella dei Compact Disc (CD). Le loro superfici sono ricoperte di materiale magnetico la cui configurazione consente la memorizzazione delle informazioni. Sulla superficie di ogni piatto stanno, sospese, le testine di lettura e scrittura, attaccate al braccio del disco. La superficie di ogni piatto è divisa logicamente in tracce circolari, che a loro volta sono suddivise in settori. L’insieme delle tracce corrispondenti a una posizione del braccio costituisce un cilindro.

Il disco in funzione ruota tra velocità comprese tra i $60$ e $250$ giri al secondo. Questa velocità di rotazione è in relazione con la velocità di trasferimento (transfer rate), ovvero la velocità con cui i dati vengono trasferiti dall’unità a disco al calcolatore. La transfer rate è uno dei fattori che determina le prestazioni. Il secondo fattore è il cosiddetto tempo di posizionamento/tempo d’accesso casuale, che consta di due componenti: il tempo necessario a spostare il braccio del disco in corrispondenza del cilindro desiderato, detto tempo di ricerca e il tempo necessario affinché il settore desiderato si porti, tramite la rotazione del disco, sotto la testina, detto latenza di rotazione. Questi tempi sono nell’ordine dei millisecondi.

9.1.2 Dispositivi NVM

Gli NVM sono dispositivi elettrici composti da un controllore e da diversi chip di memoria a semiconduttore NAND flash utilizzati per memorizzare i dati.

Questi dispositivi

Vengono spesso inseriti in contenitori simili a unità disco, e dunque vengono chiamati dischi a stato solido, o SSD. Possiamo però trovare dispositivi NVM anche in formato di unità USB
Possono essere più affidabili dei dischi rigidi, perché non hanno parti mobili e sono in genere più veloci, perché non hanno tempo di posizionamento o latenza di rotazione
Consumano meno energia, però per contro sono più costosi e hanno una capacità inferiore rispetto ai dischi rigidi tradizionali. Nel corso del tempo, la capacità dei dispostivi NVM è aumentata più rapidamente rispetto a quella dei dischi rigidi, e il loro prezzo è diminuito, motivo per cui il loro utilizzo è in aumento

Poiché i dispositivi NVM possono essere molto più veloci rispetto ai dischi rigidi, le interfacce bus standard possono costituire un limite importante al throughpput e alcuni dispositivi NVM sono progettati per connettersi direttamente al bus di sistema.

Un dispositivo NVM è composto da moltissimi die, delle piastrine di circuiti integrati atte alla memorizzazione dei dati. Ogni die contiene blocchi che a loro volta contengono molte pagine. La scrittura in un NVM viene effettuata a livello di pagina, ma richiede più tempo della lettura. È necessario infatti cancellare completamente il blocco corrispondente e riscriverlo, con la pagina modificata. In altre parole, non è possibile sovrascrivere i dati. Il problema è alleviato dal fatto che i die hanno molteplici datapath che garantiscono l’esecuzione di operazioni in parallelo. A differenza di altri dispositivi inoltre, la durata di un NVM non si misura in anni, bensì in numero di scritture per giorno sull’unità (Drive Writes Per Day, DWPD).

9.1.2.1 Algoritmi del controllore delle NAND Flash

Poiché i dispositivi NAND non possono essere sovrascritti, e vanno prima cancellati, quando una pagina viene modificata, viene semplicmente scritta in una nuova locazione di memoria libera per risparmiare tempo e le versioni precedenti della pagina, con dati non più validi, rimangono in memoria. Per tenerne traccia, il controllore mantiene una tabella di traduzione flash (Flash Translation Layer, FTL) così da poter sapere quali blocchi contengono solo pagine non valide e pertanto cancellabili. Per non esaurire lo spazio, un garbage collector accorpa le pagine con dati validi in altre posizioni, liberando completamente blocchi che possono poi essere cancellati e riutilizzati per nuove scritture. Per migliorare il coordinamento tra nuove scritture dati e garbage collection, il dispositivo utilizza una tecnica di over-provisioning. Il produttore mette da parte un certo numero di blocchi che risulta invisibile all’utente. Tali blocchi sono utilizzati per:

Permettere la scrittura istantanea di nuove pagine da parte del controllore.
Permettere al garbage collector di svolgere il suo compito di accorpamento pagine più efficientemente, utilizzando l’area di over-provisionig come buffer.
Garantire un’area sempre disponibile per la scrittura in caso di malfunzionamenti futuri di altri blocchi.

In aggiunta, se alcuni blocchi vengono cancellati ripetutamente, mentre altri non lo sono, i blocchi frequentemente cancellati si logorano più velocemente degli altri e l’intero dispositivo avrà una vita più breve. Per questo motivo, il controllore di dispositivo cerca di alleviare questo problema con degli algoritmi che favoriscono la memorizzazione di dati su blocchi meno cancellati.

9.1.3 Memoria volatile

La DRAM, l’hardware per la memoria principale, viene spesso utilizzata come dispositivo di archivazione di massa. Più precisamente, una sezione della DRAM viene ritagliata e presentata al resto del sistema come se fosse una memoria di massa (con un file system associato). In questa maniera, dati in memoria principale possono essere salvati temporanemanete come file temporanei in memoria utilizzando le normali operazioni sui file. Infatti, sebbene i dispositivi NVM siano veloci, la DRAM è molto più veloce e le operazioni di I/O su unità RAM sono il modo piu veloce per creare, leggere, scrivere ed eliminare file.

9.1.4 Mappatura degli indirizzi

I dispositivi di archivazione sono indicizzati come vettori unidimensionali di blocchi logici, in cui un blocco logico rappresenta la più piccola unità di trasferimento. Ogni blocco logico viene mappato su un settore fisico o su una pagina di un dispositivo a semiconduttore.

Nei dischi rigidi, una zona di memoria viene identificata attraverso una tupla <settore, cilindro, testina>. Nei dispositivi NVM una pagina viene invece identificata attraverso una tupla <chip, blocco, pagina>. Per semplificare le operazioni, le tuple sono convertite in un indirizzo di blocco logico (Logic Block Address, LBA) (anche per il disco rigido, nonostante il nome). In un disco rigido, la mappatura da indirizzo a logico a fisico è difficile da effettuare nella pratica, principalmente per tre motivi:

La maggior parte delle unità presenta alcuni settori difettosi che la mappatura nasconde sostituendoli con settori di riserva collocati in altre posizioni sull’unità.

Il numero di settori per traccia non è sempre costante.
I produttori di dischi gestiscono la mappatura di LBA su indirizzi fisici internamente.

9.2 Scheduling dei dischi rigidi

Il sistema operativo ha, tra le varie responsabilità, quella di fare un uso efficiente dell’hardware. Nel caso dei dischi rigidi, far fronte a questa responsabilità significa garantire tempi di accesso contenuti e ampiezze di banda elevate. Nel caso dei dischi, il tempo d’accesso è composto da:

Il tempo di ricerca (seek time): ossia il tempo richiesto affinché il braccio dell’unità a disco sposti le testine fino al cilindro contenente il settore desiderato
La latenza di rotazione (rotational latency): il tempo necessario affinché il disco ruoti finché il settore desiderato si trovi sotto la testina.

L’ampiezza di banda (bandwidth) è definita come il numero totale di byte trasferiti diviso il tempo totale intercorso fra la prima richiesta e il completamento dell’ultimo trasferimento. Gestendo l’ordine delle richieste di I/O relative al disco si possono migliorare sia il tempo d’accesso sia l’ampiezza di banda. Se l’unità a disco desiderata e il controllore sono disponibili, la richiesta si può immediatamente soddisfare. In caso contrario le nuove richieste si aggiungono alla coda, che dovrà essere opportunamente gestita. La presenza di una coda di richieste verso un dispositivo su cui è possibile minimizzare i tempi di ricerca (seek) consente ai driver del dipostivo di migliorare le prestazioni ordinando opportunamente la coda.

9.2.1 Scheduling in ordine di arrivo – FCFS

Questo scheduling rappresenta la forma più semplice dove il servizio viene effettuato secondo l’ordine di arrivo (FCFS). Si tratta di un algoritmo equo, ma che in generale non garantisce la massima velocità di servizio. Vediamolo con un esempio: Data la coda di richieste nei cilindri $98$, $183$, $37$, $122$, $14$, $124$, $65$, $67$, la testina, una volta arrivata al cilindro $122$, deve poi effettuare un grande salto per andare al cilindro $14$, e tornare successivamente al $124$, con conseguente inefficienza di utilizzo. Se invece le richieste per i cilindri $37$ e $14$ si potessero effettuare in sequenza, la distanza totale percorsa diminuirebbe notevolmente e le prestazioni migliorerebbero di conseguenza.

9.2.2 Scheduling - SCAN

Questo algoritmo prevede che il braccio dell’unità a disco parta da un estremo del disco, si sposti verso l’altro estremo, e serva le richieste mentre attraversa i cilindri. Arrivato all’estremità, il braccio inverte la marcia e la procedura continua. Per questo motivo, viene anche chiamato algoritmo dell’ascensore. Vediamo il funzionamento ancora con l’esempio precedente. Data la coda $98$, $183$, $37$, $122$, $14$, $124$, $65$ e $67$, sappiamo che la posizione corrente è $53$, e che la direzione del movimento della testina è nella direzione del cilindro $0$. Dunque, l’unità a disco serve per prima la richiesta $37$, e poi la $14$. Una volta arrivato al cilindro $0$, inverte in senso di marcia servendo le richieste $65$, $67$, $98$, $122$, $124$ e $183$. Se arriva una nuova richiesta riferita a uno dei cilindri posti davanti alla testina essa sarà quasi immediatamente soddisfatta. In caso contrario, dovrà attendere fino a che la testina non giunga alla fine del disco e inverta la direzione di moto.

9.2.3 Scheduling – C-SCAN

L’algoritmo SCAN circolare è una variante dello scheduling SCAN concepita per garantire un tempo d’accesso meno variabile. Anche questo algoritmo, come il precedente, sposta la testina da un estremo all’altro del disco servendo le richieste lungo il percorso. Tuttavia, quando la testina giunge all’altro estremo del disco, ritorna immediatamente all’inizio del disco stesso, senza servire richieste durante il viaggio di ritorno.

9.2.4 Scheduling di dispositivi NVM

Gli algoritmi appena discussi si applicano a memorie basate su dischi meccanici e hanno come obiettivo principale la riduzione della quantità di movimento della testina del disco. I dispositivi NVM, che invece non contengono testine in movimento, usano generalemnte una semplice politica FCFS. Inoltre, siccome nei dispositivi NVM il tempo richiesto per le letture è uniforme, ma il tempo richiesto per le scritture no, alcuni scheduler per gli SSD sfruttano questa proprietà e accorpano soltanto le richieste di scrittura adiacenti, mentre le richieste di lettura sono servite in ordine FCFS.

Questa pecularità evidienza anche differenze in termini di prestazioni. Infatti, come abbiamo visto l’I/O può essere sequenziale o diretto.

L’accesso sequenziale è ottimale per i dispositivi meccanici come gli HDD e i nastri, poiché i dati da leggere o scrivere si trovano vicino alla testina di lettura/scrittura.
L’accesso casuale/diretto invece, misurato in operazioni di input/output al secondo (IOPS) provoca il movimento della testina del disco, e dunque è ottimale nei dispostivi NVM.

Dunque, il vantaggio dei dispositivi NVM è molto inferiore nel caso di trasferimenti sequenziali, dove la ricerca sui dischi rigidi è ridotta al minimo e vengono enfatizzate la lettura e la scrittura dei dati. In questi casi, per le letture, le prestazioni dei due tipi di dispositivi possono essere equivalenti o differire di un ordine di grandezza in favore dei dispositivi NVM. La scrittura su NVM è più lenta della lettura, riducendo ulteriormente il vantaggio rispetto agli HDD. Inoltre, mentre le prestazioni di scrittura su HDD restano costanti durante il ciclo di vita del del dispostivo, le prestazioni in scrittura su dispositivi NVM variano a seconda di quanto il dispositivo è pieno (ricordiamo la necessità di garbage collection e over-provisioning) e di quanto è usurato.

9.3 Rilevamento e correzione di errori

Il rilevamento e la correzione degli errori sono fondamentali per la gestione della memoria, delle reti e dei dispostivi di massa. Il rilevamento degli errori permette di determinare se si è verificato un problema in modo da arrestare un’operazione prima che essa venga propagata. Per molto tempo i sistemi di memoria hanno rilevato gli errori utilizzando i bit di parità. In questo scenario, a ogni byte in un sistema di memoria viene associato un bit di parità. Se uno dei bit nel byte è corrotto (un $1$ diventa $0$ o viceversa) la parità del byte cambia e non corrisponde piu alla parità memorizzata. Ciò permette al sistema di memoria di rilevare tutti gli errori su un singolo bit, ma non è detto che ne rilevi uno su due bit.

Un altro metodo di rilevamento degli errori è il controllo di ridondanza ciclica (Ciclic Redundancy Check, CRC), che utilizza una funzione di hash per rilevare errori su più bit. Un codice di correzione degli errori (Error Correcting Code)) è in grado di correggere il problema oltre a rilevarlo. La correzione viene eseguita utilizzando opportuni algoritmi e una certa quantità di spazio di memorizzazione aggiuntivo. Il funzionamento di ECC prevede che quando un controllore scrive un settore di dati durante il normale I/O, viene anche scritto l’ECC, calcolato a partire da tutti i byte dei dati che vengono scritti. Quando il settore viene letto, l’ECC viene ricalcolato e confrontato con il valore memorizzato. Un valore diverso da quello calcolato indica che i dati sono corrotti e che il supporto di memorizzazione potrebbe essere danneggiato.

L’ECC è in grado di correggere gli errori solo quando pochi bit sono corrotti, ossia nei casi dei cosiddetti errori reversibili (soft), mentre fallisce con gli errori irreversibili (hard).

9.5 Gestione delle unità di memoria secondaria

Tra le varie responsabilità del s.o. rientrano anche:

L’inizializzazione del dispositivo.
L’avviamento del sistema del dispositivo.
La gestione del blocchi difettosi.

Andiamo a vedere nel dettaglio questi aspetti.

9.5.1 Formattazione del disco, partizioni e volumi

Prima che un dispositivo nuovo di storage possa memorizzare dati, deve essere diviso in settori che possono essere letti o scritti dal controllore. Nel caso dei dispotivi NVM, devono essere inizializzate le pagine. Questo processo si chiama formattazione di basso livello/formattazione fisica, e consiste nel riempire il dispositivo con una speciale struttura dati per ogni locazione di memorizzazione. Tale struttura tipicamente consiste di un’intestazione, un’area per i dati e una coda. L’intestazione e la coda contengono informazioni usate dal controllore del disco e l’ECC.

Prima di usare un dispostivo come contenitore di file, il sistema operativo deve compiere tre passi:

Suddividere il dispositivo in uno o più gruppi di blocchi o pagine, dette partizioni. Alcuni s.o. e file system eseguono automaticamnte il partizionamento nel caso in cui un intero dispositivo debba essere gestito dal file system.

Creare e gestire il volume. A volte questo passaggio è implicito, come quando un file system viene inserito direttamente all’interno di una partizione. Altre volte invece è esplicito, per esempio quando più partizioni o dispositivi vengono utilizzanti insieme
Eseguire la formattazione logica, cioè la creazione di un file system. Il s.o. registra nel dispostivo le strutture dati iniziali relative al file system.

9.5.2 Blocco d’avviamento

affinché un calcolatore possa entrare in funzione, per esempio quando viene acceso o riavviato, è necessario che esegua un programma iniziale; di solito, questo programma di avviamento iniziale (bootstrap) è piuttosto semplice. Nella maggior parte dei calcolatori il bootstrap è memorizzato nel firmware (una memoria flash NVM) sulla scheda madre del sistema e mappato su una posizione di memoria nota. Il piccolo programma che carica il bootstrap, detto bootstrap loader è anche in grado di caricare dalla memoria secondaria un programma di bootstrap completo, che è memorizzato nei blocchi di avvio in una posizione fissa del dispositivo.

9.5.3 Blocchi difettosi

Le unità a disco sono strutturalmente soggette a malfunzionamenti perché sono costituite da parti mobili con basse tolleranze (si ricordi che una testina è sospesa appena sopra la superficie del disco). A volte si può verificare un guasto irreparabile, e l’unità a disco deve essere sostituita. Il suo contenuto dev’essere recuperato da una copia di backup e trasferito nella nuova unità a disco. Più di frequente, uno o più settori diventano malfunzionanti. In effetti, la maggior parte dei dischi messi in commercio contiene gia blocchi difettosi.

Nel caso di dischi semplici come quelli gestiti da un controllore IDE, i blocchi difettosi sono gestiti manualmente. Una possibile strategia consiste nell’effettuare la scansione del disco durante la formattazione, per rilevare la presenza di blocchi difettosi. Un blocco difettoso viene marcato come inutilizzabile e viene segnalato alle procedure di allocazione del file system per non utilizzarlo. Se qualche blocco diventa malfunzionante nel corso dell’ordinario uso del sistema, un programma speciale viene lanciato manualmente per individuare i blocchi difettosi e isolarli.

Unità a disco più complesse hanno strategie di recupero dei blocchi difettosi più raffinate. Il controllore mantiene una lista dei blocchi malfunzionanti dell’unità a disco che è inizializzata durante la formattazione fisica eseguita dal produttore, ed è aggiornata per tutto il periodo in cui l’unità a disco è operativa. La formazione fisica mette anche da parte dei settori di riserva non visibili al s.o.: si può istruire il controllore affinché sostituisca da un punto di vista logico un settore difettoso con uno dei settori di riserva inutilizzati. Questa strategia è nota come sector sparing/sector forwarding.

Un’alternativa al sector sparing è data da quei controllori capaci di sostituire i settori difettosi tramite la traslazione dei settori, detta sector slipping.

Anche i dispositivi NVM possono contenere bit, byte e persino pagine che sono difettose già al momento della produzione o che si degradano nel tempo. La gestione di queste aree difettose è più semplice rispetto agli HDD, perché non incide sul tempo di ricerca. È possibile in questi casi mettere da parte più pagine da utilizzare in sostituzione di quelle difettose, opure utilizzare spazio dell’area di over-provisioning.

9.6 Gestione dell’area di swapping

La gestione dell’area di swapping è un altro compito di basso livello del sistema operativo. La memoria virtuale usa lo spazio dei dischi come estensione della memoria centrale: poiché l’accesso alle unità a disco è molto più lento dell’accesso alla memoria centrale, l’uso dell’area di swapping ridure notevolmente le prestazioni del sistema. L’obiettivo principale nella progettazione e realizzazione di un’area di swapping è di fornire il migliore throughput per il sistema di memoria virtuale.

9.6.1 Uso dell’area di swapping

L’area di swapping è usata in modi diversi da sistemi operativi diversi, in funzione degli algoritmi di gestione della memoria utilizzati. I sistemi che adottano lo swapping dei processi nella memoria, per esempio, possono usare l’area di swapping per mantenere l’intera imamgine del processo, inclusi i segmenti dei dati e del codice. I sistemi a paginazione, invece, possono semplicemente memorizzarvi pagine non contenute nella memoria centrale. Lo spazio richiesto da quest’area per un sistema può quindi variare da pochi megabyte ad alcuni gigabyte, a seconda della quantità di memoria fisica, della quantità di memoria virtuale che esso deve sostenere, e del modo in cui quest’ultima è usata. Alcuni sistemi consigliano la quantità da riservare all’area di swapping.

9.6.2 Collocazione dell’area di swapping

Le possibili collocazioni sono due: all’interno del normale file system, o in una partizione del disco a sé stante. Se l’area di swapping è semplicemente un grande file all’interno del file system, si possono usare le ordinarie funzioni del file system per crearla, assegnargli un nome e allocare spazio per essa. In alternativa, l’area di swapping si può creare in un’apposita partizione del disco non formattata: in essa non è presente alcuna struttura relativa al file system e alle directory, ma si usa uno speciale gestore dell’area di swapping per allocare e rimuovere i blocchi. Esso adotta algoritmi ottimizzati rispetto alla velocità di accesso, e non rispetto allo spazio occupato, dato che all’area di swapping si accede molto più frequentemente che al file system. Il metodo delle raw partition assegna una dimensione fissa all’area di swapping al momento della creazione delle partizioni del disco, e l’aumento delle dimensioni dell’area deve quindi passare attraverso il ripartizionamento del disco, oppure attraverso la creazione di un’altra area di swapping.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 11.

Gestione della memoria

Mon, 15 Apr 2024 00:00:00 +0000

Background

La memoria consiste in un grande array di byte ciascuno con il proprio indirizzo. La CPU legge le istruzioni dalla memoria basandosi sul contatore di programma. Queste istruzioni possono causare dei load o dei store aggiuntivi da e verso la memoria.

Hardware di base

Mappatura degli indirizzi

Un programma può essere caricato in qualunque parte della memoria fisica e gli indirizzi dal punto di vista del programma sono simbolici. La mappatura (binding) tra istruzioni e dati a indirizzi di memoria può avvenire con la seguente gerarchia:

Il compilatore mappa gli indirizzi simbolici a degli indirizzi rilocabili (p.e. “14 byte dall’inizio del modulo”)
Il linker o il loader mappano gli indirizzi rilocabili a quelli assoluti (p.e. “74014”).

Più in generale, la mappatura può avvenire a qualunque livello:

Compile time: se, a tempo di compilazione, si sa dove il programma risiederà in memoria, il compilatore può mappare direttamente gli indirizzi simbolici a indirizzi assoluti, generando codice assoluto (absolute code). Se la locazione del processo cambia sarà necessario ricompilare il programma
Load time: se non si sa dove il programma risiederà, è necessario generare codice rilocabile. In questo caso la mappatura agli indirizzi fisici è demandata a tempo di loading. Se l’indirizzo di partenza cambia, è necessario eseguire il loading del codice utente di nuovo
Execution time: se il processo può essere spostato in memoria durante la sua esecuzione, la mappatura avverrà a tempo di esecuzione. È necessario un hardware speciale per questo tipo di mappatura. La maggior parte dei sistemi operativi utilizza questo metodo

Spazio degli indirizzi logico e fisico

Un indirizzo comunemente generato dalla CPU è chiamato indirizzo logico, mentre un indirizzo visto dalla memoria, caricato nel registro degli indirizzi di memoria (memory-address register) è chiamato indirizzo fisico. La mappatura a compile e load time genera gli stessi indirizzi logici e fisici, tuttavia la mappatura a execution time no. In quest’ultimo caso, l’indirizzo logico viene chiamato indirizzo virtuale (utilizzeremo tuttavia entrambi i termini logico e virtuale allo stesso modo). La mappatura run-time da indirizzi virtuali a quelli fisici è operata con dell’hardware chiamato unità di gestione della memoria (memory-management unit, MMU). Introduciamo un semplice schema di mappatura che generalizza quello del registro base. Tale registro viene chiamato ora registro di rilocazione (relocation register). Questo valore è aggiunto a ogni indirizzo da un processo utente nel momento in cui l’indirizzo è inviato in memoria. Se il registro rilocabile è 14000, allora 0 sarà mappato a 14000 e 346 a 14346. Il programma non ha accesso all’indirizzo fisico, solo a quello rilocabile.

Loading dinamico

È possibile demandare il caricamento delle routine utilizzate da un programma al momento effettivo in cui esse vengono chiamate. Questa pratica si chiama loading dinamico (dynamic loading). In particolare, le routine vengono salvate in uno speciale formato rilocabile. Quando una routine esegue e chiama un’altra routine, la routine chiamante controlla se la routine chiamata è già presente nella memoria. Se non la trova, la carica dalla memoria secondaria, aggiorna la tabella degli indirizzi del programma e passa il controllo alla routine chiamata. Questo metodo è efficace nel caso di routine molto grandi che vengono chiamate poco frequentemente, come ad esempio le routine in caso di errore.

Il loading dinamico non richiede speciale supporto da parte del s.o. ed è di responsabilità dello sviluppatore. Il s.o. può tuttavia fornire delle routine di libreria per implementare il loading dinamico.

Linking dinamico e librerie condivise

Esistono due modi per mappare un programma alle librerie di routine di cui ha bisogno per eseguire:

Static linking: il loader tratta le librerie di routine come ogni altro modulo oggetto e le combina all’interno dell’eseguibile del programma. L’eseguibile contiene tutto ciò che gli serve per eseguire ma incrementa in dimensioni poiché trasporta con sé le librerie di routine (o perlomeno le routine di cui ha bisogno per eseguire). In aggiunta, le librerie di routine vengono caricate in memoria centrale sprecando memoria
Dynamic linking: il linker cerca le librerie di routine tra quelle di sistema e fa il linking col programma utente quando questo viene eseguito. Il programma è più leggero e le librerie, chiamate Dynamically Linked Libraries (DLL), possono essere condivise anche da altri programmi. Per tale motivo vengono anche chiamate librerie condivise (shared libraries). Sono molto utilizzate nei sistemi Windows e Linux e il linguaggio C fa largo uso di questo sistema. Quando un programma richiede una routine di una libreria dinamica il loader cerca la DLL e la carica in memoria aggiornando gli indirizzi. In questo modo è possibile aggiornare le DLL senza dover ricompilare tutto il programma, tuttavia per evitare che un programma utilizzi inavvertitamente delle DLL di una versione non compatibile, solitamente viene incluso un numero di versione che viene controllato prima del linking. Questa alternativa al dynamic loading richiede aiuto da parte del s.o. per permettere al processo che ha richiesto la libreria di accederci

Allocazione contigua della memoria

La memoria centrale deve accomodare sia il s.o. che i vari processi utente. Abbiamo quindi bisogno di allocare lo spazio nella migliore maniera possibile. La memoria viene divisa generalmente in due partizioni: una per il s.o. e una per i processi utente. È possibile allocare la memoria s.o. negli indirizzi più bassi o più alti della memoria, tuttavia molti s.o. (tra cui Windows e Linux) utilizzano gli indirizzi alti, quindi tratteremo questo caso. Nell’allocazione di memoria contigua ogni processo utente viene allocato in una singola sezione di memoria contigua a quella del processo successivo.

Protezione della memoria

Possiamo prevenire che un processo acceda alla memoria di un altro processo combinando la tecnica del registro base e del registro di rilocazione precedentemente visto. Dal momento che gli indirizzi rilocabili vanno da 0 (incluso) al valore specificato dal registro di rilocazione limite (escluso), quando una CPU esegue un’istruzione di accesso alla memoria è necessario solamente che controlli che l’indirizzo rilocabile sia minore del registro limite. In tal caso, la CPU aggiungerà il registro base per ottenere l’indirizzo fisico.

Allocazione della memoria

Uno dei metodi più semplici di allocazione della memoria consiste nell’allocare, per ciascun processo, una partizione di memoria di dimensione variabile. Inizialmente tutta la memoria è disponibile ed è considerata un buco (hole). Progredendo col caricamento la memoria conterrà più buchi vuoti. Nel momento in cui un processo entra in memoria il s.o. tiene in conto dei requisiti di memoria di cui necessita. Se non c’è memoria sufficiente è possibile rifiutare il processo o piazzarlo in una coda di attesa. Se un processo è di dimensione minore rispetto a un buco contenuto nell’insieme dei buchi, può venire piazzato lì. In tal caso, se c’è molto spazio all’interno del buco, solo una parte viene allocata al processo e la rimanente ritorna nell’insieme dei buchi. Quando un processo finisce di eseguire lasciando un buco, se questo è adiacente a un altro buco entrambi vengono uniti in un buco soltanto. Questa è una singola istanza di strategia per risolvere il problema dell’allocazione dinamica di spazio. Tra le strategie più utilizzate troviamo

First-fit: alloca il primo buco che è grande abbastanza per contenere il processo. La ricerca può cominciare all’inizio dell’insieme dei buchi o nella locazione dove la ricerca si era precedentemente conclusa. La ricerca si ferma una volta trovato il buco
Best-fit: alloca il buco più piccolo che può contenere il processo. La ricerca richiede di controllare tutti i buchi disponibili (se non è ordinata per dimensione)
Worst-fit: alloca il buco più grande che può contenere il processo. La ricerca richiede di contrallare tutti i buchi disponibili (se non è ordinata per dimensione). Questa strategia lascia più spazio rimanente nel buco e può essere più utile della strategia best-fit

Frammentazione

Con gli algoritmi first-fit e best-fit, l’allocazione e la rimozione dei processi può generare problemi di frammentazione. Esistono due tipologie di frammentazione:

Frammentazione esterna: in seguito all’allocazione e rimozione dei processi si creano molti piccoli buchi all’interno della memoria. Questo fenomeno accade quando ci sarebbe memoria sufficiente per ospitare un nuovo processo ma questa è frammentata in molteplici buchi non contigui. Analisi statistiche sull’algoritmo first-fit confermano che allocando $N$ blocchi, altri $0.5N$ blocchi vengono persi per via della frammentazione ($50$-percent rule). Una soluzione al problema è il compattamento (compaction) per cui la memoria viene riorganizzata per accostare i buchi e unirli insieme. Questa metodologia non è possibile se la rilocazione è stata fatta a compile o load time. Bisogna inoltre calcolare il costo della rilocazione, quando questa è possibile. La strategia più semplice, ma anche costosa, è quella di spostare tutti i processi da una parte e i buchi dall’altra. È anche possibile permettere che lo spazio degli indirizzi di un processo non sia contiguo. Questa strategia è chiamata paging ed è la più comune nei s.o.
Frammentazione interna: supponiamo di avere un processo da $18,462$ bytes allocato in un buco da $18,464$ bytes. Il peso della struttura usata per tracciare i due byte rimanenti sarebbe maggiore dei due byte stessi comportando uno spreco di memoria. Per ovviare a questa situazione è possibile allocare un blocco fisso di memoria, maggiore della memoria richiesta dal processo. La rimanenza tra la memoria del blocco e quella effettivamente occupata dal processo viene chiamata frammentazione interna.

Paging

Il paging è una tecnica che consiste nel dividere la memoria fisica in blocchi di dimensione fissa chiamati frame, e quella logica in pagine (pages). Quando un processo viene eseguito, le sue pagine vengono caricate in memoria. L’idea di separare la memoria fisica da quella logica ci permette di avere indirizzi logici di, per esempio, $64$ bit senza avere una memoria fisica da $2^{64}$ bit.

Ogni indirizzo generato dalla CPU viene diviso in due parti:

Numero di pagina ($p$): è usato come un indice dentro una tabella di pagine, relativa a un singolo processo e contenente l’indirizzo fisico di ogni frame
Offset di pagina ($d$): è l’offset utilizzato per riferirsi alla locazione esatta nel frame

L’MMU esegue i seguenti step per tradurre un indirizzo logico in quello fisico

Estrarre il numero di pagina $p$ e utilizzarlo per cercare nella tabella delle pagine
Estrarre il corrispondente numero di frame $f$ dalla tabella delle pagine
Rimpiazzare il numero di pagina $p$ nell’indirizzo logico col numero di frame $f$
Aggiungere l’offset $d$ al numero di frame $f$ per ottenere l’indirizzo fisico

Un programma, prima dell’esecuzione esprime la sua dimensione in pagine. Se richiede $n$ pagine, è necessario disporre di $n$ frame per poterlo allocare. La mappatura è gestita dal s.o., che tiene traccia dei frame liberi attraverso una tabella di frame (frame table). Questa struttura indica quali frame sono liberi, quali sono occupati e da che processi sono occupati.

Supporto hardware

Ogni PCB del processo contiene un puntatore alla tabella delle pagine a esso associate, e questa tabella viene caricata dalla CPU ogni volta che un processo entra in esecuzione. L’implementazione hardware della tabella può essere fatta in vari modi e di solito consiste in una serie di registri dedicati che rendono la traduzione efficiente. L’uso dei registri è efficiente se la tabella è piccola. Per tabelle più grosse, i registri non bastano ed è necessario ricorrere a un registro base di tabelle di pagine (Page-Table Base Register, PTBR) situato in memoria centrale. Cambiare le tabelle di pagine richiede solo di cambiare il valore di questo registro riducendo sostanzialmente il tempo di context switch.

buffer di traduzione look-aside

Se salviamo la tabella delle pagine in memoria risparmiamo tempo nel context switch ma l’accesso alla tabella situata nella memoria peggiora le performance poiché dobbiamo accedere alla PTBR ricavare l’indirizzo e accedere poi alla pagina cercata. È possibile implementare una piccola e veloce cache di ricerca chiamata buffer di traduzione Look-aside (Translation Look-aside Buffer, TLB). Ogni entry del TLB consiste di una chiave e di un valore. Quando arriva un oggetto, questo viene confrontato con tutte le chiavi finché non avviene un match e viene ritornato il corrispondente valore. Il TLB è piccolo in dimensioni, da $32$ a $1024$ entry. Alcune CPU hanno una TLB per le istruzioni e una per i dati.

$$effective\ access\ time = \underbrace{hit\ ratio \times page\ access\ time}_{TLB\ hit} + (1 - hit\ ratio) \times \underbrace{(page\ table\ access\ time + page\ access\ time)}_{TLB\ miss}$$

Protezione

Per evitare che un processo acceda a dei frame in memoria a esso non assegnati è possibile inserire un bit di validità per entry nella tabella delle pagine, il cosiddetto bit valido-invalido (valid-invalid bit). Ogni volta che un processo vuol fare un accesso a una pagina virtuale, il rispettivo bit di validità viene controllato e se è impostato a falso, l’accesso viene catturato dal s.o.

Questo approccio presenta un problema: se l’ultima pagina riservata al processo è utilizzata solo parzialmente, il processo ha la possibilità di accedere anche ai byte della sezione di frammentazione interna. Più in generale, è raro che un processo utilizzi tutto lo spazio degli indirizzi che gli è stato reso disponibile. Alcuni sistemi utilizzano un registro di lunghezza della tabella delle pagine (Page-Table Length Register, PTLR) che indica la dimensione della tabella delle pagine per controllare il range di validità degli indirizzi a cui un processo può accedere.

È possibile estendere l’approccio del bit di validità per includere altri bit read-only, write-only, etc.

Pagine condivise

Struttura di una tabella di pagine

In questa sezione esploriamo tecniche comuni per strutturare una tabella di pagine.

Paging gerarchico

Con i sistemi moderni, una tabella di pagine può diventare molto grande e occupare molto spazio in memoria. Per esempio, su un sistema a $32$-bit con pagine di dimensione $4$K ($2^{12}$) una tabella delle pagine consisterebbe di $2^{32} / 2^{12}$ entry. Se la dimensione di un’entry è, ad esempio di $4$ byte, consumeremmo $4$MB di memoria a processo solo per la tabella delle pagine.

È possibile ovviare al problema inserendo una struttura di paging gerarchica in cui anche la tabella delle pagine viene spezzettata. Ad esempio nel precedente sistema, se associamo $20$ bit al numero di pagina e $12$ bit all’offset, potremmo “paginare” le pagine, dividendo i $20$ bit in $10$ per un primo livello e $10$ per un secondo livello di paging. Il livello più interno si riferirebbe sempre al numero di pagina, mentre quello esterno sarebbe relativo a una tabella delle pagine esterna, che indicizza la tabella delle pagine interna.

Tabelle hash di pagine

Un approccio per gestire gli spazi degli indirizzi molto grandi ($32$bit) è quello di utare una tabella hash di pagine (hashed page table) con il valore di hash corrispondente al numero virtuale di pagina. Ogni entry della tabella contiene una lista concatenata. Ogni elemento consiste in tre campi:

Il numero di pagina virtuale
Il valore del frame mappato
Un puntatore all’elemento successivo nella lista concatenata

Il numero di pagina virtuale nell’indirizzo virtuale viene salvato nella tabella hash. Viene quindi confrontato con il primo campo, la lista corrispondente viene selezionata e si cerca il frame corrispondente. Una variazione utile per indirizzi a $64$bit è quella a tabella di pagine raggruppate (clustered page table) in cui un valore hash si può riferire a diverse pagine piuttosto che a una soltanto. In questo caso, una singola entry nella tabella si può riferire a diversi frame. Questa variante è utile in presenza di spazi degli indirizzi sparsi

Tabella di pagine invertita

Swapping

Standard swapping

Swapping con paging

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 9.

Gestione della memoria virtuale

Thu, 18 Apr 2024 00:00:00 +0000

In questa lezione andremo ad approfondire i concetti sottostanti la memoria virtuale, la sua implementazione e alcune considerazioni sulla sua efficenza computazionale

Background

Ci sono varie casistiche da considerare per poter risparmiare memoria:

Un programma non utilizza tipicamente tutto il codice con cui è stato implementato. Le routine di errore, per esempio, vengono chiamate solo all’occorrenza.
Alcune strutture dati (p.e. array) possono venire allocate con maggiore memoria di quella effettivamente richiesta

Per tali motivi, è utile caricare solo parte di un programma in memoria, utilizzando una memoria virtuale. I vantaggi sono:

Un programma può accedere a uno spazio virtuale molto più grande di quello fisico
Molti programmi possono eseguiti contemporaneamente
Sono necessarie meno operazioni di I/O per lo swapping completo dei programmi
Il programmatore non si deve preoccupare di gestire la memoria permettendogli di sviluppare codice più facilmente

La memoria virtuale ci permette anche di:

Condividere librerie di sistema
Condividere codice in comune (p.e. a seguito di una fork)
Avviare una comunicazione tramite memoria condivisa

Paging su richiesta

Come detto, è possibile caricare solo parzialmente le parti di un processo, demandando il caricamento di pagine specifiche solamente quando queste sono richieste dal processo per continuare a eseguire. Questa tecnica si chiama paging su richiesta (demand paging).

Concetti base

Il paging su richiesta necessita di un meccanismo per indicare quali pagine nella tabella delle pagine sono state caricate in memoria. È possibile, a tal proposito, utilizzare il bit di validità. Quando il bit è impostato a true, la pagina è valida, altrimenti la pagina non è valida oppure non è stata caricata in memoria centrale. Nel caso si provi ad accedere una pagina con bit a false, viene emesso un errore page fault che viene catturato dal s.o. La procedura di gestione dell’errore è la seguente:

Viene controllata una tabella interna al processo per vedere se la pagina non è valida
Se la pagina non è valida il processo termina, se è valida la pagina viene caricata
Viene cercato un frame libero per l’allocazione della pagina
La pagina viene letta dalla memoria secondaria e allocata nel nuovo frame
Viene aggiornata la tabella delle pagine per indicare che la pagina è ora valida
L’esecuzione del processo riprende

Nel caso estremo, un processo può essere inizializzato con zero pagine in memoria (pure demand paging).

Gli addendi A e B vengono letti
Il risultato A + B viene computato
Il risultato viene salvato in C

Nel caso in cui C corrispondesse a una locazione di memoria in una pagina invalida, il processo va in interruzione e alla sua ripresa deve ricomputare la somma. Nel caso di istruzioni che implicano lo spostamento di grossi moli di dati, questo può peggiorare le performance. Esistono varie soluzioni a questo problema.

Lista di frame liberi

Performance del paging su richiesta

$$effective\ access\ time = (1 - p) \times ma + p \times page\ fault\ time$$

Il tempo di page fault (page fault time) è il più complicato da stimare, ed è composto da tre operazioni principali:

Servire l’interrupt del page fault
Leggere la pagina
Riprendere l’esecuzione del processo

Copy-on-write

Quando un processo genitore chiama la fork() e genera un processo figlio, questo ultimo riceverebbe anche una copia dello spazio degli indirizzi su cui operare. Tuttavia considerando che molti figli invocano exec() immediatamente dopo la loro creazione, è possibile minimizzare il consumo di memoria utilizzando la tecnica di copy-on-write. In particolare, tutte le pagine condivise vengono etichettate come copy-on-write e vengono duplicate solamente all’occorrenza, quando uno dei due processi ci esegue un’operazione di scrittura. Solamente le pagine modificabili vengono etichettate, quelle non-modificabili (p.e. quelle contenenti il codice eseguibile) no.

Sostituzione delle pagine

Sostituzione delle pagine standard

Quando un processo registra un page fault, l’algoritmo standard per la sostituzione di pagine funziona nel seguente modo:

Trova la locazione della pagina da caricare nella memoria secondaria
Trova un frame libero
1. Se c’è un frame libero usalo
2. Se non c’è usa un algoritmo di sostituzione pagina per selezionare un victim frame
3. Salva il victim frame nella memoria secondaria (se necessario), cambia la pagina e il frame
Carica la pagina desiderata nel frame liberato, aggiorna le tabelle delle pagine e dei frame
Continua a eseguire il processo dal momento del page fault

Due trasferimenti sono richiesti, uno per la pagina in entrata e uno per la pagina in uscita. Si può ridurre l’overhead utilizzando un modify bit (o dirty bit). In caso positivo, viene prima copiata nella memoria secondaria, altrimenti viene semplicemente sovrascritta.

Ovviamente, all’aumentare del numero di frame disponibili il numero di page fault decrementa, assumendo un andamento simil-esponenziale.

Per implementare correttamente il paging su richiesta è necessario trovare un algoritmo di allocazione dei frame e uno di sostituzione pagine.

Sostituzione pagine FIFO

L’algoritmo più semplice è il first-in, first-out (FIFO) che seleziona la pagina più vecchia in memoria per la sostizione. Non serve salvare il tempo in cui le pagine sono state allocate, basta utilizzare una coda FIFO. Se una pagina in uso viene sostituita, questa verrà riallocata in memoria al prossimo page fault, garantendo comunque la correttezza dell’algoritmo.

Questo algoritmo può incorrere in un fenomeno strano noto come l’anomalia di Belady, per il quale aumentando il numero di frame disponibili, aumenta il numero di page fault.

Sostituzione pagine ottimale

Esiste un algoritmo ottime di sostituzione pagine, chiamato OPT o MIN. La regola è semplice e consiste nel sostituire la pagina che non verrà utilizzata per il periodo più lungo di tempo. Sfortunatamente l’algoritmo è difficile da implementare perché richiede di stimare l’utilizzo delle pagine nel futuro. Per tale motivo l’algoritmo viene utilizzato solo come riferimento. Questo algoritmo non soffre dell’anomalia di Belady.

Sostituzione pagine LRU

Questo algoritmo è spesso utilizzato. Il problema principale è l’implementazione del meccanismo di memoria, che viene generalmente fatta in due modi:

Contatori: Associamo a ogni entry della tabella delle pagine un tempo di utilizzo e aggiungiamo alla CPU un clock logico o un contatore. Ogni volta che avviene l’accesso a una pagina, il suo tempo viene registrato nella entry di riferimento. In caso di sostituzione, la pagina con il tempo minore viene scelta per la sostituzione. Questo metodo richiede lo scorrimento delle pagine per la ricerca della pagina LRU e un’operazione di scrittura per l’aggiornamento delle pagine a ogni accesso in memoria.
Stack: Un altro approccio è uello di utilizzare una pila di numeri di pagina. Quando una pagina viene acceduta e messa sopra la pila. In questa maniera le pagine utilizzate più recentemente sono mantenute sopra lo stack. La struttura dati da utilizzare è una lista doppiamente concatenata con un pontatore alla testa e alla coda. Rimuovere una pagina e metterla sopra la pila richiede la modifica di sei puntatori nel peggiore dei casi. Non è necessaria la ricerca, anche se l’update è più costoso. Questo approccio è particolarmente vantaggioso.

Anche questo algoritmo non soffre dell’anomalia di Belady. Sia l’algoritmo ottimale che questo algoritmo vengono chiamati algoritmi stack poiché si può dimostrare che l’insieme di pagine in memoria su $n$ frame è sempre il sottoinsieme di pagine che sarebbe in memoria con $n + 1$ frame. Per la sostituzione LRU, l’insieme di pagine in memoriea consisterebbe nelle $n$ pagine utilizzate più recentemente.

Sostituzione pagine LRU approssimata

Non tutti i sistemi forniscono hardware sufficiente per supportare LRU. Molti sistemi forniscono qualche aiuto, ma nella forma di bit di riferimento (reference bit). Il bit di riferimento per una pagina è impostato dall’hardware a $1$ ogni volta che la pagina viene acceduta. È possibile esaminare e selezionare la pagina da sostituire tra quelle che non sono state utilizzate, anche se non conosciamo l’ordine di utilizzo.

Algoritmo con i bit di riferimento aggiuntivi

L’algoritmo FIFO con un solo bit di riferimento viene chiamato algoritmo di sostituzione pagine con seconda possibilità (second-chance page-replacement algorithm). È possibile utilizzare il bit di riferimento assieme a quello di modifica per ottenere un’analisi più completa dell’utilizzo della pagina:

(0, 0) pagina non recentemente usata, né modifica. Rappresenta il candidato migliore per la sostituzione
(0, 1) pagina non recentemente usata, ma modificata. La sua sostituzione comporta una scrittura in memoria secondaria
(1, 0) pagina recentemente usata, ma non modificata. Probabilmente verrà usata di nuovo
(1, 1) pagina recentemente usata e modificata. Verrà probabilmente riusata e in ogni caso dovrebbe venire scritta nella memoria secondaria

Sostituzione pagine basata su conteggio

Ci sono altri algoritmi che possono essere usati per la sostituzione delle pagine. Per esempio possiamo tenere un riferimento al numero di volte in cui una pagina è stata acceduta.

Algoritmi di buffering di pagina

Allocazione dei frame

Passiamo ora al problema dell’allocazione dei frame ai vari processi. In particolare, ci chiediamo quanti frame dobbiamo assegnare a ciascun processo? è

Numero di frame minimo

È importante allocare un numero minimo di frame per processo. Le motivazioni di questa scelta sono due:

Col diminuire di frame disponibili per un processo, i suoi page fault aumentano, diminuendo le prestazioni.
Quando avviene un page fault prima che un’istruzione sia completata, l’istruzione va ri-eseguita da capo.

Solitamente un’architettura stabilisce il numero minimo di frame e imposta il numero massimo con il numero di frame totali nella memoria fisica.

Algoritmi di allocazione

$S = \sum_{i = 1}^n s_i$

e calcolare quanti frame allocare a ogni processo utilizzando la seguente formula

$a_i = s_i / S \times m$.

Dobbiamo poi regolare il numero affinché sia un intero maggiore del numero minimo di frame e minore di $m$. Questo algoritmo si chiama di allocazione proporzionale.

Lo svantaggio è che non fa distinzioni tra processi a bassa e ad alta priorità. Questi ultimi potrebbero avere delle maggiori esigenze in termini di memoria per garantire la loro esecuzione in tempi stretti. È possibile quindi calcolare lo spazio di allocazione anche in base alla priorità del processo.

Allocazione globale vs locale

Possiamo classifiare gli algoritmi di sostituzione pagine in due macro categorie:

Rimpiazzamento globale: un processo può selezionare un qualunque frame di sostituzione, anche tra i frame posseduti da altri processi. È utile per esempio per permettere a processi ad alta priorità di selezionare all’occorrenza frame da processi a bassa priorità. Il problema principale è che il comportamento di paging di ogni processo varia e non è quindi facile gestire prevedere quali pagine selezionare. In ogni caso, il rimpiazzamento globale è la scelta più comunemente adottata.
Rimpiazzamento locale: un processo può selezionare un frame di sostituzione solo tra quelli a esso allocati. Il problema principale è che il processo non può accedere a frame di altri processi che potrebbe essere sottoutilizzati.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 10.

Memoria di massa

Thu, 25 Apr 2024 00:00:00 +0000

In questa lezione vedremo i meccanismi di base e il modo in cui i s.o. traducono le loro proprietà fisiche in memoria logica tramite la mappatura degli indirizzi.

Struttura dei dispositivi di memorizzazione

I dischi magnetici (o rigidi) e i dispositivi NVM cosituiscono i supporti fondamentali di memoria secondaria dei computer. Di seguito riportiamo le loro caratteristiche principali.

Dischi rigidi

Dispositivi NVM

Gli NVM sono dispositivi elettrici composti da un controllore e da diversi chip di memoria a semiconduttore NAND flash utilizzati per memorizzare i dati.

Questi dispositivi

Vengono spesso inseriti in contenitori simili a unità disco, e dunque vengono chiamati dischi a stato solido, o SSD. Possiamo però trovare dispositivi NVM anche in formato di unità USB
Possono essere più affidabili dei dischi rigidi, perché non hanno parti mobili e sono in genere più veloci, perché non hanno tempo di posizionamento o latenza di rotazione
Consumano meno energia, però per contro sono più costosi e hanno una capacità inferiore rispetto ai dischi rigidi tradizionali. Bisogna dire però che nel corso del tempo, la capacità dei dispostivi NVM è aumentata più rapidamente rispetto a quella dei dischi rigidi, e il loro prezzo è diminuito, motivo per cui il loro utilizzo è in aumento

Poiché i dispositivi NVM possono essere molto più veloci rispetto ai dischi fissi, le interfacce bus standard possono costituire un limite importante al throughpput e alcuni dispositivi NVM sono progettati per connettersi direttamente al bus di sistema.

Un dispositivo NVM è composto da moltissimi die, delle piastrine di circuiti integrati atte alla memorizzazione dei dati. Ogni die contiene blocchi che a loro volta contengono molte pagine. La scrittura in un NVM viene effettuata a livello di pagina, ma richiede più tempo della lettura. È necessario infatti cancellare completamente il blocco corrispondente e riscriverlo, con la pagina modificata. In altre parole, non è possibile sovrascrivere i dati. Il problema è alleviato dal fatto che i die hanno molteplici datapath per garantire l’esecuzione di operazioni in parallelo. A differenza di altri dispositivi inoltre, la durata di un NVM non si misura in anni, bensì in numero di scritture per giorno sull’unità (Drive Writes Per Day, DWPD).

Algoritmi del controllore delle NAND Flash

Permettere la scrittura istantanea di nuove pagine da parte del controllore
Permettere al garbage collector di svolgere il suo compito di accorpamento pagine più efficientemente, utilizzando l’area di over-provisionig come buffer
Garantire un’area sempre disponibile per la scrittura in caso di malfunzionamenti futuri di altri blocchi.

Memoria volatile

La DRAM, o memoria volatile, viene spesso utilizzata come dispositivo di archivazione di massa. Più precisamente, le RAM agiscono come memoria secondaria, ma sono create da driver di periferica che ritagliano una sezione della DRAM di sistema e la presentano al resto del sistema come se fosse una memoria di massa. Sono utilizzate perché, mentre cache e buffer sono allocati dal programmatore o dal sistema operativo, le unità RAM consentono all’utente di salvare temporanemanete i dati in memoria utilizzando le normali operazioni sui file. Inoltre, sebbene i dispositivi NVM siano veloci, la DRAM è molto più veloce e le operazioni di I/O su unità RAM sono il modo piu veloce per creare, leggere, scrivere ed eliminare i file e il loro contenuto.

Mappatura degli indirizzi

Nei dispositivi NVM una tupla del tipo <chip, blocco, pagina> viene mappata su un vettore di blocchi logici. Un indirizzo di blocco logico (Logic Based Address, LBA) è più semplice da utilizzare rispetto a una tupla <settore, cilindro, testina> o <chip, blocco, pagina>. La mappatura da indirizzo a logico a fisico è difficile da effettuare nella pratica, principalmente per tre motivi.

La maggior parte delle unità presenta alcuni settori difettosi che la mappatura nasconde sostituendoli con settori di riserva collocati in altre posizioni sull’unità. In questo caso, l’indirizzo del blocco logico rimane sequenzialie, ma la posizione del settore fisico cambia
Il numero di settori per traccia non è sempre costante
I produttori di dischi gestiscono la mappatura di LBA su indirizzi fisici internamente

Gli algoritmi che gestiscono gli HDD prediligono comunque indirizzi logici correlati a quelli fisici.

Scheduling dei dischi rigidi

Il tempo di ricerca (seek time): ossia il tempo richiesto affinché il braccio dell’unità a disco sposti le testine fino al cilindro contenente il settore desiderato
La latenza di rotazione (rotational latency): il tempo necessario affinché il disco ruoti finché il settore desiderato si trovi sotto la testina.

Scheduling in ordine di arrivo – FCFS

Questo scheduling rappresenta la forma più semplice dove il servizio viene effettuato secondo l’ordine di arrivo (FCFS). Si tratta di un algoritmo equo, ma che in generale non garantisce la massima velocità di servizio. Vediamolo con un esempio: Data la coda di richieste nei cilindri $98$, $183$, $37$, $122$, $14$, $124$, $65$, $67$, la testina, una volta arrivata al cilindro $122$, deve poi effettuare un grande salto per andare al cilindro $14$, e tornare successivamente al $124$, con conseguente inefficienza di utilizzo. Se invece le richieste per I cilindri $37$ e $14$ si potessero effettuare in sequenza, la distanza totale percorsa diminuirebbe notevolmente e le prestazioni migliorerebbero di conseguenza.

Scheduling - SCAN

Scheduling – C-SCAN

Scheduling di dispositivi NVM

Questa pecularità evidienza anche differenze in termini di prestazioni. Infatti, come abbiamo visto l’I/O può essere sequenziale o diretto.

L’accesso sequenziale è ottimale per i dispositivi meccanici come gli HDD e i nastri, poiché i dati da leggere o scrivere si trovano vicino alla testina di lettura/scrittura.
L’accesso casuale/diretto invece, misurato in operazioni di input/output al secondo (IOPS) provoca il movimento della testina del disco, e dunque è ottimale nei dispostivi NVM.

Rilevamento e correzione di errori

L’ECC è in grado di correggere gli errori solo quando pochi bit sono corrotti, ossia nei casi dei cosiddetti errori reversibili (soft), mentre fallisce con gli errori irreversibili (hard).

Gestione delle unità di memoria secondaria

Tra le varie responsabilità del s.o. rientrano anche:

L’inizializzazione del dispositivo
L’avviamento del sistema del dispositivo
La gestione del blocchi difettosi

Andiamo a vedere nel dettaglio questi aspetti.

Formattazione del disco, partizioni e volumi

Prima di usare un dispostivo come contenitore di file, il sistema operativo deve compiere tre passi:

Suddividere il dispositivo in uno o più gruppi di blocchi o pagine, dette partizioni. Alcuni s.o. e file system eseguono automaticamnte il partizionamento nel caso in cui un intero dispositivo debba essere gestito dal file system.

Creare e gestire il volume. A volte questo passaggio è implicito, come quando un file system viene inserito direttamente all’interno di una partizione. Altre volte invece è espliciito, per esempio quando più partizioni o dispositivi vengono utilizzanti insieme
Eseguire la formattazione logica, cioè la creazione di un file system. Il s.o. registra nel dispostivo le strutture dati iniziali relative al file system.

Blocco d’avviamento

Blocchi difettosi

Un’alternativa al sector sparing è data da quei controllori capaci di sostituire i settori difettosi tramite la traslazione dei settori, detta sector slipping.

Gestione dell’area di swapping

La gestione dell’area di swapping e’ un altro compito di basso livello del sistema operativo. La memoria virtuale usa lo spazio dei dischi come estensione della memoria centrale: poiché l’accesso alle unità a disco è molto più lento dell’accesso alla memoria centrale, l’uso dell’area di swapping ridure notevolmente le prestazioni del sistema. L’obiettivo principale nella progettazione e realizzazione di un’area di swapping è di fornire il migliore throughput per il sistema di memoria virtuale.

Uso dell’area di swapping

L’area di swapping è usata in modi diversi da sistemi operativi diversi, in funzione degli algoritmi di gestione della memoria utilizzati. I sistemi che adottano lo swapping dei processi nella memoria, per esempio, possono usare l’area di swapping per mantenere l’intera imamgine del processo, inclusi i segmenti dei dati e del codice. I sistemi a paginazione, invece, possono semplicemente memorizzarvi pagine non contenute nella memoria centrale. Lo spazio rihiesto da quest’area per un sistema può quindi variare da pochi megabyte ad alcuni gigabyte, a seconda della quantità di memoria fisica, della quantità di memoria virtuale che esso deve sostenere, e del modo in cui quest’ultima è usata. Alcuni sistemi consigliano la quantità da riservare all’area di swapping.

Collocazione dell’area di swapping

Le possibili collocazioni sono due: all’interno del normale file system, o in una partizione del disco a sé stante. Se l’area di swapping è semplicemente un grande file all’interno del file system, si possono usare le ordinarie funzioni del file system per crearla, assegnarli un nome e allocare spazio per essa. In alternativa, l’area di swapping si può creare in un’apposita partizione del disco non formattata: in essa non è presente alcuna struttura relativa al file system e alle directory, ma si usa uno speciale gestore dell’area di swapping per allocare e rimuovere i blocchi. Esso adotta algoritmi ottimizzati rispetto alla velocità di accesso, e non rispetto allo spazio impiegato su disco, dato che all’area di swapping si accede molto più frequentemente che al file system. Il metodo delle raw partition assegna una dimensione fissa all’area di swapping al moemnto della creazione delle partizioni del disco, e l’aumento delle dimensioni dell’area deve quindi passare attraverso il ripartizionamento del disco, oppure attraverso la creazione di un’altra area di swapping in qualche altra unità a disco del sistema.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 11.

Sistemi I/O

Wed, 15 May 2024 00:00:00 +0000

I compiti principali di un calcolatore sono l’I/O e l’elaborazione. L’I/O è preponderante in attività come la navigazione in Internet o la modifica di un file. Il ruolo del s.o. nell’I/O è quello di gestire e controllare le sue operazioni di base. In questa sezione discutiamo dei principi di funzionamento dei dispositivi I/O.

I progettisti dei s.o. si focalizzano molto sulla gestione dei dispositivi a causa della loro natura variegata e delle velocità dei dispositivi di I/O. Il sottosistema I/O gestisce questa complessità, separandola dal kernel. Nonostante l’aumento della standardizzazione nelle interfacce hardware e software, la proliferazione di dispositivi I/O diversificati presenta sfide di integrazione. Per affrontare questo problema, il kernel utilizza moduli di driver di dispositivo per incapsulare i dettagli del dispositivo, garantendo un’interfaccia di accesso uniforme all’interno del sottosistema di I/O.

Hardware di I/O

I computer interagiscono con dispositivi diversi categorizzati in tipi di archiviazione, trasmissione e interfaccia uomo-macchina. Nonostante questa varietà, sono sufficienti pochi concetti per comprendere come siano connessi e come il s.o. li controlli. I dispositivi comunicano con i computer tramite segnali, sia cablati che wireless, attraverso dei punti di connessione, o porte.

Le connessioni fisiche possono formare bus, che sono un insieme di fili con un protocollo definito che specifica l’insieme dei messaggi che si possono inviare. I bus sono caratterizzati da vari metodi di segnalazione, velocità, larghezze di banda e metodi di connessione. Una struttura tipica del bus PC include un bus PCIe che collega il sottosistema processore-memoria ai dispositivi veloci e un bus di espansione che collega dispositivi più lenti come tastiere e porte USB. PCIe trasmette dati su uno o più “corsie”, delle connessioni full-duplex per la trasmissione dei dati.

Un controller è una collezione di componenti elettronici che gestisce una porta, un bus o un dispositivo.

Memory-Mapped I/O

Per facilitare i trasferimenti I/O, il processore comunica con un controller che contiene registri per dati e segnali di controllo. Questa comunicazione coinvolge tipicamente istruzioni speciali per I/O che attivano il trasferimento di byte o parole a specifici indirizzi di porta I/O. Queste istruzioni attivano linee di bus per selezionare il dispositivo appropriato e trasferire dati da o verso i registri del dispositivo. In alternativa, i dispositivi possono supportare l’I/O mappato in memoria, dove i registri di controllo del dispositivo sono nella memoria principale. Qui, la CPU esegue richieste di I/O utilizzando istruzioni standard di trasferimento dati per accedere a questi registri presso le loro posizioni mappate nella memoria fisica. Il controllo del dispositivo I/O di solito coinvolge quattro registri: dati-in e dati-out, stato, controllo.

Registro di dati-in: letto dall’host per ricevere input
Registro di dati-out: scritto dall’host per inviare output
Registro di stato: contiene bit che indicano stati come il completamento del comando, la disponibilità dei dati e gli errori del dispositivo
Registro di controllo: scritto dall’host per avviare comandi o modificare modalità del dispositivo, come tipo di comunicazione, controllo di parità, lunghezza della parola e selezione della velocità. I registri di dati sono solitamente di dimensioni comprese tra $1$ e $4$ byte. Alcuni controller incorporano chip FIFO, che estendono la capacità del controller memorizzando più byte di dati di input o output. Questi chip FIFO possono temporaneamente contenere una piccola raffica di dati fino a quando il dispositivo o l’host non è pronto per riceverli

Polling

Il protocollo di interazione tra un host e un controller può essere complesso, ma il concetto base è semplice. Ad esempio, consideriamo uno scenario in cui vengono utilizzati $2$ bit per gestire la relazione produttore-consumatore. Il controller comunica il suo stato tramite il bit di busy nello status register, impostandolo quando è occupato e cancellandolo quando è pronto per il prossimo comando. Al contrario, l’host esprime le sue intenzioni attraverso il bit di command-ready nel command register, impostandolo quando un comando è pronto per l’esecuzione. Questo consente una comunicazione coordinata tra l’host e il controller come segue:

L’host controlla continuamente il bit di busy finché non diventa $0$
L’host imposta il bit di scrittura nel command register e invia un byte al data-out register
L’host imposta il bit di command-ready
Dopo aver rilevato il bit di command-ready impostato, il controller imposta il bit di busy
Il controller esamina il command register, identifica il comando di scrittura, recupera il byte dal data-out register e esegue l’operazione di I/O sul dispositivo.
Successivamente, il controller cancella il bit di command-ready, reimposta il bit di errore nello status register per indicare un’operazione di I/O del dispositivo riuscita e cancella il bit di busy per indicare il completamento

L’host monitora costantemente lo status register finché il bit di busy non si cancella, un metodo noto come attesa attiva (busy-waiting) o polling.

Interrupt

L’hardware della CPU dispone di una linea di richiesta di interrupt che si attiva dopo ogni istruzione. Quando viene rilevato un segnale di interrupt, la CPU salva il suo stato e salta a un indirizzo di memoria fisso per una routine di gestione degli interrupt. Questa routine identifica la causa dell’interrupt, la gestisce, ripristina lo stato della CPU e ritorna all’esecuzione normale.

I controller dei dispositivi generano interrupt inviando un segnale sulla linea di interrupt, che la CPU gestisce tramite il gestore di interrupt. La gestione è cruciale nei sistemi moderni e il meccanismo di interrupt di base consente alle CPU di reagire a eventi asincroni, ma i moderni s.o. richiedono capacità di gestione più avanzate.

In un calcolatore moderno, le funzioni di interrupt sono gestite dalla CPU e dal controller hardware degli interrupt. Le CPU di solito dispongono di due linee di richiesta di interrupt: una non mascherabile per eventi critici come gli errori di memoria, e una mascherabile per le richieste dei dispositivi.

Gli interrupt sono gestiti tramite un vettore di interruzioni, che contiene gli indirizzi dei gestori delle interruzioni specializzati. Quando esistono più dispositivi rispetto agli indirizzi del vettore, viene utilizzato il chaining delle interruzioni, dove ogni elemento del vettore punta a un elenco di gestori. Questa struttura bilancia il sovraccarico di una grande tabella di interruzioni e l’efficienza del dispatch a un singolo gestore.

Il meccanismo di interrupt include livelli di priorità che consentono alla CPU di posticipare gli interrupt a bassa priorità senza bloccarle tutte, consentendo a quelli ad alta priorità di interrompere quelli a bassa priorità.

Durante l’avvio, un s.o. identifica i dispositivi hardware e installa i relativi gestori di interrupt. I controller dei dispositivi generano interrupt durante le operazioni di I/O per vari eventi come l’output completato o l’input disponibile. Gli interrupt gestiscono anche eccezioni come errori di divisione per zero o accesso a memoria protetta.

Nei system call, gli interrupt software, o trap, facilitano la comunicazione tra le applicazioni utente e il kernel. Questi interrupt hanno una priorità inferiore rispetto agli interrupt dei dispositivi.Inoltre, gli interrupt gestiscono il flusso di controllo del kernel, dando priorità a compiti come il completamento delle letture dal disco.

I gestori ad alta priorità gestiscono compiti critici, come l’avvio di operazioni di I/O in sospeso, mentre i gestori a bassa priorità gestiscono compiti meno urgenti, garantendo un utilizzo efficiente del disco. La gestione degli interrupt nei moderni sistemi operativi coinvolge il dispacciamento degli interrupt a bassa priorità quando la CPU è disponibile. Questi interrupt completano i compiti di I/O a livello utente prima di programmare le applicazioni per l’esecuzione.

Accesso diretto alla memoria

Per trasferimenti efficienti di grandi quantità di dati, come quelli dei dischi rigidi è possibile utilizzare i controller di accesso diretto alla memoria (Direct Memory Access, DMA) che gestiscono autonomamente i trasferimenti di dati, senza l’utilizzo della CPU. L’host inizia il DMA scrivendo un blocco di comandi specificando sorgente, destinazione e conteggio dei byte. La tecnica di scatter-gather consente trasferimenti complessi tramite un singolo comando.

Gli attuali sistemi operativi impiegano la mappatura della memoria per trasferimenti I/O diretti tra dispositivi e spazio degli indirizzi utente, migliorando le prestazioni.

La comunicazione tra il controller DMA e il controller del dispositivo avviene tramite i cavi DMA-request e DMA-acknowledge. Il controller del dispositivo segnala la disponibilità dei dati tramite DMA-request, inducendo il controller DMA ad accedere alla memoria. Una volta riconosciuto, i dati vengono trasferiti e i segnali vengono rimossi. Al termine, il controller DMA interrompe la CPU. Sebbene il “cycle stealing” possa rallentare brevemente il calcolo della CPU, il trasferimento dei dati generalmente migliora le prestazioni del sistema. Alcune architetture utilizzano l’accesso diretto alla memoria virtuale (Direct Virtual Memory Access, DVMA), bypassando l’intervento della CPU e l’uso della memoria principale. I kernel in modalità protetta impediscono i comandi diretti ai dispositivi per proteggere dati e stabilità del sistema.

Interfaccia di applicazione I/O

In questa sezione discutiamo delle interfacce e delle schematizzazioni utilizzate dai s.o. per trattare i dispositivi I/O in maniera uniforme.

L’idea generale nello sviluppo degli algoritmi di funzionamento dei dispositivi I/O è quella di comunicare col dispositivo attraverso un’interfaccia di funzioni standard e poi incapsulare le differenze in moduli kernel chiamati driver di dispositivo. Lo scopo dei driver è di nascondere le differenze tra i controller di dispositivo al sottosistema I/O. In altre parole, rendere il sottosistema I/O indipendente dall’hardware semplifica il lavoro degli sviluppatori del s.o.

I produttori di dispositivi possono invece sviluppare un dispositivo per essere compatibile con un’interfaccia di controllore già presente (p.e. SATA) oppure possono scrivere driver di dispositivo per interfacciarsi con i s.o. più popolari. Sfortunatamente ogni s.o. ha i propri standard per i driver di interfaccia.

Alcune scelte nel protocollo di comunicazione dei dispositivi:

Trasferimento a flusso di caratteri o a blocchi: un dispositivo può trasferire i byte uno ad uno oppure a gruppi
Accesso sequenziale o diretto: un dispositivo può trasferire i dati seguendo un ordine fisso oppure puntando a posizioni non necessariamente contigue
Sincrono o asincrono: un dispositivo può trasferire i dati in accordo ad altri aspetti del sistema oppure con tempi di risposta variabili, non coordinati agli eventi del s.o.
Condiviso o dedicato: un dispositivo può essere utilizzato da molti processi contemporaneamente oppure da un solo processo alla volta
Velocità di esecuzione: i dispositivi hanno velocità che spaziano da pochi byte al secondo a diversi gigabyte al secondo
Read-write, read only o write once: alcuni dispositivi supportano la scrittura e la lettura, mentre altri solo una delle due operazioni. Inoltre in alcuni dispositivi la scrittura può essere effettuata solo una volta e il dato diventa read only, dopo.

Molti s.o. hanno un meccanismo di escape (o backdoor) che permette alle applicazioni di passare comandi arbitrari direttamente ai driver.

Dispositivi con trasferimento a blocchi e a caratteri

L’interfaccia per dispositivi a blocchi (block-device interface) è pensata per dispositivi che gestiscono il trasferimento dei dati a unità chiamate blocchi. Il s.o. preferisce a volte accedere al dispositivo considerandolo come un semplice array di blocchi. Questo modo di accesso è chiamato raw I/O. È possibile che un’applicazione che utilizza il dispositivo si occupi direttamente di gestire il buffering e il locking di regioni condivise. In questo caso, i s.o. moderni possono passare a una modalità in cui tali funzionalità sono disabilitate per il processo. Nel mondo UNIX, questa modalità è chiamata direct I/O. Un esempio di dispositivo a blocchi è il file.

La tastiera, il mouse o il modem sono un esempi di interfaccia per dispositivi a caratteri (character-device interface). Le chiamate di sistema leggono o inseriscono un carattere alla volta.

I dispositivi di rete

Nel caso di dispositivi di rete utilizziamo delle interfacce chiamate socket (prese). Il meccanismo è simile a quello di una presa elettrica. L’applicazione genera una socket che permette a un indirizzo remoto di connettersi. A sua volta l’applicazione si connette alla socket generata dall’applicazione in remoto.

Clock e timer

I clock e i timer forniscono le seguenti tre funzioni:

Danno il tempo corrente
Danno il tempo rimasto
Impostano delle deadline per emettere un evento in un istante di tempo prefissato

L’hardware preposto si chiama timer di intervallo programmabile. Viene impostato a un determinato istante di tempo per generare un interrupt. Si può impostare per emettere l’evento una volta o periodicamente. Un clock/timer può essere soggetto a deviazioni (drift) dal tempo che deve tracciare. Tali deviazioni possono essere corrette attraverso l’utilizzo di protocolli specifici come Network Time Protocol (NTP) che mantiene la precisione di clock di sistema a livelli paragonabili a quelli degli orologi atomici.

I/O asincrono e non bloccante

Possiamo dividere le chiamate a sistema in tre categorie:

I/O bloccante: una volta effettuata la chiamata, il thread chiamante attende la sua esecuzione e riceve il risultato dell’operazione di I/O. Spesso le chiamate I/O non sono bloccanti, poiché i dispositivi I/O hanno tempi imprevedibili, tuttavia il s.o. fornisce anche la possibilità di avere chiamate bloccanti poiché sono più semplici da gestire
I/O non bloccante: una volta effettuata la chiamata, questa ritorna velocemente. Il risultato è il numero di byte che sono stati trasferiti (tutti, una parte o nessuno). Un esempio di processo che richiede I/O non bloccante è un’interfaccia utente che processa indipendentemente l’input da mouse e da tastiera mentre visualizza gli output sul monitor
I/O asincrono: una volta effettuata la chiamata, questa ritorna immediatamente, senza il risultato, che viene computato completamente ma in futuro

I/O vettorizzato

Alcuni s.o. permettono di effettuare molteplici operazioni I/O attraverso un’unica chiamata a sistema.

Sottosistema di I/O del kernel

I kernel forniscono vari servizi relativi all’I/O, raggruppati nel sottosistema I/O.

Scheduling I/O

Per programmare un insieme di richieste I/O è importante stabilire un ordine di esecuzione che massimizzi le performance del dispositivo. Gli sviluppatori implementano gli scheduler I/O utilizzando una coda d’attesa che può essere riordinata all’occorrenza, sulla base delle performance ma anche mantenendo un’equità d’utilizzo da parte delle applicazioni sulla base delle priorità. Vediamo ora alcuni aspetti dello scheduling I/O.

Buffering

Un buffer è un’area di memoria che salva i dati in trasferimento tra due dispositivi e o tra un dispositivo e un’applicazione. Il buffering viene effettuato per tre ragioni:

Gestire lo squilibrio tra la velocità di produzione e di consumo dei dati. Per esempio, quando è necessario scrivere in una memoria secondaria un messaggio proveniente da Internet, è possibile programmare due buffer nella memoria principale. La rete inizia a trasmettere dati in un buffer. Quando questo è pieno la rete scrive sul secondo buffer, mentre il primo viene svuotato in memoria secondaria, e così via, finché il messaggio completo non viene salvato. Questo metodo è chiamato double buffering
Gestire lo squilibrio tra le dimensioni delle unità di trasferimento. Per esempio, in una rete, un messaggio da inviare viene frammentato in pacchetti piccoli che vengono ricevuti in buffer di destinazione per poi essere riassemblati
Gestire la semantica di copia per applicazioni I/O. Nel caso un’applicazione voglia scrivere nella memoria secondaria un buffer di dati prodotti, deve assicurarsi che il buffer non cambi durante la copia. Per questo motivo, è possibile creare un buffer kernel che operi la copia mentre il buffer dell’applicazione continua a produrre dati.

Caching

Una cache è una regione di memoria che mantiene copie di dati e garantisce un accesso più efficiente della memoria normale. La differenza con il concetto di buffer è che la cache mantiene una copia per definizione, mentre un buffer può contenere dati originali.

A volte una regione di memoria può essere utilizzata sia per buffering che per caching. Per esempio, il s.o. utilizza dei buffer per mantenere nella memoria principale alcune informazioni presenti in memoria secondaria utili a un processo. Se un altro processo vuole accedere agli stessi dati in sola lettura il s.o. può utilizzare il buffer in memoria come una cache e condividere i dati, minimizzando così lo spazio consumato in memoria.

Spooling

Uno spool è un buffer che mantiene l’input inviato a un dispositivo in attesa che venga processato. Per esempio, è possibile inviare più input contemporaneamente a una stampante. In questo caso il primo input viene processato e gli altri vengono salvati in file temporanei. Il sistema di spooling si occupa di gestire la coda degli input.

Gestione degli errori

Un s.o. che utiliza meccanismi di protezione della memoria si può difendere contro molto tipi di errori hardware e d’applicazione evitando un generale malfunzionamento di sistema. In generale, un s.o. ritornerà un bit di informazione che indica lo stato della chiamata (successo o fallimento). In UNIX, viene anche ritornato un intero indicante il tipo dell’errore.

Protezione I/O

Un utente potrebbe accidentalmente o volontariamente alterare la normale operatività di un sistema chiedendo di eseguire istruzioni I/O illegali. Per tale motivo tutte le operazioni I/O sono considerate privilegiate e l’utente non le può avviare direttamente, ma deve invece chiedere al s.o. di eseguirle. Il s.o., in modalità monitor, controlla che la richiesta sia valida ed esegue l’I/O richiesta.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 12.

10 Interfaccia del file system

Tue, 15 Apr 2025 00:00:00 +0000

Il file system è essenziale nei s.o. per l’archiviazione e l’accesso a dati e programmi. È composto da file che memorizzano informazioni e da una struttura logica a directory che organizza i file. La maggior parte dei file system risiede su dispositivi di archiviazione. In questa lezione discuteremo degli aspetti dei file, delle strutture dei file system, della condivisione dei file tra processi e utenti, e delle modalità di protezione dei file.

10.1 Aspetti base dei file

Il file è un’unità di memorizzazione logica delle informazioni che fornisce un’astrazione delle caratteristiche fisiche di archiviazione dei dati.

10.1.1 Concetto di file

file di testo: sequenza di caratteri organizzati in linee (e possibilmente pagine).
file sorgente: sequenza di funzioni, ognuna delle quali è ulteriormente organizzata come dichiarazioni seguite da istruzioni eseguibili.
file eseguibile: sequenza di sezioni di codice che il loader può caricare in memoria ed eseguire.

10.1.2 Attributi dei file

I file sono denominati, tipicamente per comodità, con stringhe come example.c. La denominazione rende i file indipendenti dagli utenti e dai sistemi, consentendo una facile condivisione e manipolazione. I s.o. possono o meno differenziare tra caratteri maiuscoli e minuscoli nei nomi. Con i trasferimenti o le modifiche interne, i file mantengono i loro nomi, per garantire coerenza nel loro accesso e nella loro gestione. Alcune informazioni che caratterizzano i file:

Nome: il nome simbolico del file è l’unica informazione conservata in forma user-readable.
Identificatore: tag unico, di solito un numero, che identifica il file all’interno del file system. È il nome non-user-readable del il file.
Tipo: necessario per i sistemi che supportano diversi tipi di file.
Locazione: un puntatore a un dispositivo e alla posizione del file su tale dispositivo.
Dimensione: la dimensione attuale del file (in byte, parole o blocchi) e eventualmente la dimensione massima consentita sono incluse in questo attributo.
Protezione: le informazioni sul controllo degli accessi determinano chi può fare lettura, scrittura, esecuzione, e così via.
Timestamp e identificazione dell’utente: queste informazioni possono essere conservate per la creazione, l’ultima modifica e l’ultimo utilizzo. Possono essere inoltre utili per la protezione, la sicurezza e il monitoraggio dell’uso.

I nuovi file system offrono attributi estesi come la codifica dei caratteri e i checksum dei file. Le informazioni sui file, compresi gli attributi, sono memorizzate nelle directory sullo stesso dispositivo. Le voci di directory includono tipicamente il nome del file e un identificatore unico, con la dimensione della directory.

10.1.3 Operazioni sui file

Un file è un tipo di dato astratto con operazioni definite come creare, scrivere, leggere, etc. I sistemi operativi offrono chiamate di sistema per eseguire queste operazioni. Comprendere queste operazioni di base facilita l’implementazione di funzioni simili come rinominare i file.

Creare un file: consiste nel trovare spazio nel file system e fare un’entrata in una directory.
Aprire un file: varie operazioni (tranne creare e eliminare) richiedono una chiamata open() di file, che restituisce un handle di file per il suo utilizzo.
Scrivere un file: richiede di specificare un handle di file aperto e i dati da scrivere, aggiornando un puntatore di scrittura sequenziale.
Leggere un file: richiede di specificare l’handle del file e la locazione di memoria per il blocco successivo, aggiornando un puntatore di lettura per letture sequenziali.
Rilocamento all’interno di un file consiste nel riposizionamento del puntatore di locazione corrente del file, senza eseguire operazioni I/O. Questa operazione è nota anche come file seek.
Eliminare un file: coinvolge la ricerca della directory per il file, il rilascio del suo spazio e la cancellazione o marcatura della sua voce di directory.
Troncare un file: consente di cancellare i contenuti del file mantenendo gli attributi reimpostando la lunghezza del file a zero e rilasciando il suo spazio.

Le operazioni di base sui file includono creazione, lettura, scrittura, riposizionamento, eliminazione e troncamento dei file, coinvolgendo spesso ricerche nelle directory. I sistemi richiedono spesso una chiamata open() prima dell’uso del file per evitare costanti ricerche nelle directory. I file possono essere aperti implicitamente o esplicitamente con la chiamata di sistema open(), specificando modalità di accesso come sola lettura o lettura-scrittura. Ogni processo mantiene una tabella per-processo per tracciare i file aperti (tabella dei file aperti), con tabelle a livello di sistema contenenti informazioni sulla posizione e sui metadati dei file. Le operazioni open() e close() sono più complesse negli ambienti multi-processo, coinvolgendo tabelle per-processo e a livello di sistema per tracciare l’uso dei file e mantenere la coerenza.

Le operazioni di creazione, lettura, scrittura, eliminazione costituiscono la base dei sistemi di gestione dei file. Tali operazioni servono per l’esecuzione di compiti più complessi come la copia o la rinomina dei file. Attributi come la lunghezza e la proprietà di un file possono essere direttamente accessibili e modificati attraverso operazioni specifiche. In molti sistemi, è richiesta una chiamata open() esplicita prima di utilizzare un file per ottimizzare le prestazioni del sistema ed eliminare ricerche ridondanti nelle directory. All’apertura, le informazioni sul file sono memorizzate in una tabella a livello di sistema, mentre ogni processo mantiene la propria tabella per tracciare i file aperti. Negli ambienti con processi multipli, la gestione dell’accesso ai file diventa più intricata, richiedendo una sincronizzazione accurata tra processi e tabelle a livello di sistema. Questo coordinamento garantisce coerenza e previene conflitti tra gli accessi simultanei ai file. Inoltre, alcuni sistemi aprono automaticamente i file al loro primo riferimento e li chiudono al termine del programma per semplificare la gestione dei file per i programmatori. Nonostante le variazioni nell’implementazione, una gestione efficiente dei file è essenziale per garantire l’integrità dei dati e l’affidabilità del sistema.

10.1.4 Tipi di file

I tipi di file sono un aspetto cruciale per il corretto funzionamento di un s.o., dal momento che i s.o. riconoscono solo i tipi di file per i quali sono programmati. I tipi sono spesso indicati da estensioni nei nomi dei file, che aiutano nel loro riconoscimento. Estensioni come .exe o .sh indicano file che contengono eseguibili. I programmi ricorrono alle estensioni per il riconoscimento dei tipi di file supportati, come .java per i file sorgente Java o .docx per i documenti di Microsoft Word.

UNIX utilizza un semplice codice noto come magic number all’inizio dei file per indicare il tipo di dati. Le estensioni dei nomi dei file sono utili all’utente e non al s.o., fornendo dunque suggerimenti sui contenuti dei file piuttosto che regole per il loro utilizzo.

10.1.5 Struttura dei file

Il tipo di un file può anche indicare l’organizzazione dei suoi dati, ovvero la struttura prevista dal programma che legge il file. Inoltre i s.o. stessi possono richiedere che i file aderiscano ad alcune strutture per la loro corretta elaborazione. Il supporto a più strutture di file può rendere il codice del s.o. più ingombrante e complesso. D’altro canto, quando un file viene codificato in una struttura non supportata dal s.o., si possono verificare problemi. Per esempio, supponiamo che un s.o. supporti file di testo ed eseguibili, e che vogliamo implementare un tipo di file crittografato. Questo tipo non è interpretabile dal s.o. ed è quindi necessario istruirlo a non utilizzare il meccanismo di riconoscimento tipi oppure abbandonare l’idea di implementare un meccanismo crittografico. Per risolvere il problema, alcuni s.o. come UNIX e Windows impongono requisiti minimi per le strutture di file, interpretandoli come sequenze di 8 bit e supportando solo la struttura di file eseguibile per le funzionalità di base del sistema. È possibile così definire altre strutture di file e sarà compito delle applicazioni fornire il codice per interpretarle.

10.1.6 Struttura interna dei file

Per l’indirizzamento a una specifica locazione in un file, il s.o. utilizza spesso un approccio basato su blocchi. L’I/O della memoria di massa lavora con blocchi di dimensioni fisse, tipicamente non sono allineati con i record logici. Per risolvere il problema, più record logici vengono compattati in blocchi fisici. Ciò garantisce efficienza nell’archiviazione e nel recupero dei dati. Così facendo, si verifica frammentazione interna a livello di blocco, poiché le dimensioni dei file spesso non sono multipli della dimensione del blocco. I diversi file system gestiscono la frammentazione interna in modo diverso, con dimensioni di blocco più grandi che portano a una maggiore frammentazione.

10.2 Metodi d’accesso

I file memorizzano dati, accessibili e leggibili in memoria attraverso vari metodi. I s.o. offrono diversi metodi di accesso ai dati, ponendo una sfida progettuale nella scelta del metodo più adatto per applicazioni specifiche. Di seguito, vediamo due esempi di accesso.

10.2.1 Accesso sequenziale

Con l’accesso sequenziale i dati vengono letti e scritti in ordine, record per record, ed è comunemente utilizzato da editor e compilatori. Le operazioni di lettura fanno avanzare un puntatore di file e leggono la porzione successiva di dati, mentre le operazioni di scrittura aggiungono dati in coda al file e modificano il puntatore alla fine. Un file può essere reimpostato all’inizio, e alcuni sistemi consentono di saltare avanti o indietro di un numero definito di record. Questo metodo di accesso funziona universalmente su dispositivi sequenziali e ad accesso casuale.

10.2.2 Accesso diretto

Con l’accesso diretto un file viene diviso in record logici di dimensione fissa e i programmi possono leggere o scrivere in un record. Questo metodo è fondamentale per database e grandi set di dati. Le operazioni sui file includono read(n) e write(n) laddove n è il numero di blocco. I numeri di blocco sono codificati in maniera relativa rispetto all’inizio del file e vengono poi tradotti in indirizzi fisici. Assumendo una lunghezza del record di $L$ byte La richiesta per un record $N$ si traduce in richieste di I/O per $L$ byte in posizione $L \cdot N$. Alcuni s.o. supportano solo un tipo di accesso ai file.

10.3 Struttura delle directory

Le directory fungono da tabelle di simboli, che traducono i nomi dei file nei loro control block (analoghi ai process control block) e offrono vari schemi organizzativi per facilitare l’inserimento, la cancellazione, la ricerca e le operazioni di elenco. Quando si progetta un sistema di directory, è cruciale allineare la struttura con le operazioni previste:

Ricerca di un file: la ricerca dev’essere efficiente di file specifici, potenzialmente includendo il pattern matching con sottostringhe che compongono i nomi di file simili.
Creazione di un file: è essenziale poter creare nuovi file e incorporarli nella struttura delle directory.
Eliminazione di un file: i file dovrebbero essere eliminabili dalla directory quando non sono più necessari. Il file system dovrebbe disporre di metodi di deframmentazione della directory.
Elencamento di una directory: è necessario elencare tutti i file all’interno di una directory e la directory a cui un file è associato.
Rinominazione di un file: i nomi dei file dovrebbero poter essere modificabili per riflettere le modifiche nei contenuti o nell’uso del file. La rinominazione può anche permettere il cambiamento della sua posizione all’interno della directory.
Attraversamento del file system: accedere a tutte le directory e ai file al loro interno può essere necessario per scopi di backup, spesso raggiunto copiando i dati su supporti di archiviazione secondari o sul cloud per proteggersi da guasti del sistema.

10.3.1 Directory a un livello

In una struttura delle directory a un livello tutti i file vengono memorizzati in una sola directory, semplificando la gestione ma ponendo limitazioni quando il numero dei file aumenta o quando ci sono più utenti. Ogni file deve avere un nome univoco. Anche per un singolo utente, gestire molti file su una singola directory può risultare complicato, evidenziando la necessità di strutture di directory più complesse.

10.3.2 Directory a due livelli

Nella struttura delle directory a due livelli, ogni utente ha una directory dei file utente (User File Directory, UFD), mentre la directory dei file principale (Master File Directory, MFD) indicizza le UFD degli utenti. Gli utenti possono avere file con nomi identici all’interno delle loro UFD. Un programma di sistema separato viene utilizzato per creare ed eliminare le UFD, di solito eseguibile dagli amministratori. Sebbene risolva i problemi di collisione dei nomi, isola gli utenti e complica l’accesso ai file tra di loro. Per accedere ai file in un’altra directory dell’utente, si deve specificare sia il nome utente che il nome del file.

10.3.3 Directory con struttura ad albero

Estendere la struttura delle directory a un albero di altezza arbitraria consente agli utenti di creare sotto-directory, organizzando i file in modo più efficiente. Ogni file nel sistema ha un nome del percorso univoco all’interno di questa struttura ad albero. Le directory (o le sotto-directory) contengono insiemi di file (o altre sotto-directory), ed è presente una directory radice (root directory) in cima. In molte implementazioni, i file e le directory vengono distinti attraverso l’utilizzo di un bit e il s.o. implementa il formato di file “directory” che viene gestito attraverso chiamate di sistema apposite. Di solito, ogni processo ha la propria directory corrente, contenente file rilevanti, ma è possibile usare una chiamata di sistema per cambiare directory. La directory iniziale di un utente viene impostata all’accesso. I sottoprocessi ereditano di solito la directory corrente del genitore.

I nomi dei percorsi possono essere assoluti, a partire dalla radice, o relativi, originati a partire dalla directory corrente. In UNIX e Linux, i percorsi assoluti iniziano con /, mentre i percorsi relativi si basano sulla directory corrente.

Consentire agli utenti di creare sotto-directory permette un organizzazione logica dei propri file, ad esempio per argomento o tipo di file. La cancellazione delle directory viene implementata seguendo una tra due politiche principali. Alcuni s.o. permettono di eliminare solamente directory vuote, mentre altri offrono un’opzione per eliminare le directory insieme ai loro contenuti. Anche se la seconda politica è più conveniente, essa comporta rischi di eliminazione accidentale. Nelle directory strutturate ad albero, gli utenti possono accedere ai file di altri utenti utilizzando nomi di percorso assoluti o relativi, o cambiando la loro directory corrente. Questa flessibilità consente una gestione efficiente dei file e la collaborazione tra gli utenti.

10.3.4 Directory con grafo aciclico

Nei progetti collaborativi, le directory condivise facilitano il lavoro congiunto consentendo a più utenti di accedere e modificare i file contemporaneamente. A differenza delle copie, le directory condivise contengono una singola istanza di ciascun file, garantendo che le modifiche apportate da un utente siano immediatamente visibili agli altri. La capacità di condividere sotto-directory assicura un accesso coerente ai nuovi file in tutte le posizioni condivise, semplificando la collaborazione.

La struttura a grafo aciclico, a differenza delle strutture ad albero, consente directory condivise, permettendo a file o sotto-directory di essere associati a più posizioni all’interno del file system. Questo meccanismo di condivisione migliora l’efficienza e il coordinamento nei progetti collaborativi. L’implementazione di file (o sotto-directory) condivisi può essere realizzata tramite:

La creazione di link, ovvero puntatori al file
La duplicazione del file. È necessario mantenere l’integrità dei dati tra le due copie

L’eliminazione di file condivisi in strutture a grafi aciclici è complessa e presenta tre problemi:

Quando un link viene eliminato bisogna decidere se rimuovere il file a esso associato
Quando un file viene eliminato gli eventuali link relativi a esso diventano pendenti (dangling) e puntano a una posizione vuota
Se dei nuovi dati vanno a occupare una posizione puntata da link pendenti, tali link punteranno a dei dati non corretti.

Per risolvere questi problemi, esistono due approcci:

Rimuovere il link senza eliminare il file a esso associato. Se il file stesso viene eliminato, possiamo:
- Cercare tutti i suoi link ed eliminarli. Questo approccio richiede di mantenere una struttura che elenchi i link al file
- Non eliminare i link. Nel momento in cui uno di questi link viene usato, si controlla che il file a cui puntano sia quello corretto. In caso contrario, viene lanciato un errore di accesso illegale a file.
In UNIX e Windows, i link vengono lasciati e sta all’utente controllare se il file originale è stato eliminato o sostituito.
Mantenere il file finché tutti i suoi riferimenti non vengono cancellati. È possibile associare al file un contatore ai suoi riferimenti. Quando il contatore scende a $0$, il file può venire eliminato. Un garbage collector entra in funzione a intervalli periodici e controlla tutti i file, eliminandoli in caso il contatore sia a $0$. UNIX utilizza questo approccio con link non-simbolici (hard).

Infine, alcuni sistemi optano per vietare del tutto le directory o i collegamenti condivisi.

10.3.5 Directory con grafo generale

Con una struttura a grafo aciclico, prevenire i cicli diventa fondamentale per mantenere l’integrità del file system. Sebbene inizialmente si parta con una struttura ad albero, l’introduzione di collegamenti può rompere la gerarchia, portando a una struttura a grafo generica. Gli algoritmi di attraversamento devono garantire una ricerca efficiente senza ripassare sezioni condivise per evitare blocchi delle prestazioni o cicli infiniti causati.

Determinare quando un file può essere rimosso in modo sicuro diventa difficile. In presenza di cicli, infatti, la reference count di un file potrebbe non scendere mai a $0$ anche quando il “ciclo” non è più accessibile. Sono necessari algoritmi di garbage collection specializzati per rintracciare i file che non possono essere acceduti. Tali algoritmi sono tuttavia dispendiosi in termini di tempo e raramente utilizzati. Rintracciare cicli è ugualmente dispendioso, per cui la soluzione più semplice consiste nel non seguire i link durante lo scorrimento del file system.

10.4 Protezione

Garantire la sicurezza delle informazioni in un sistema informatico comporta di occuparsi di aspetti quali affidabilità e protezione.

L’affidabilità è tipicamente ottenuta tramite copie ridondanti dei file, spesso salvate a intervalli regolari per mitigare i rischi di perdita dati da guasti hardware, errori o cancellazioni accidentali.

Le misure di protezione variano, dalle autenticazioni degli utenti tramite password sui laptop alla crittografia dello storage secondario per prevenire l’accesso non autorizzato e l’implementazione di firewall per proteggersi dalle violazioni di rete. Nei sistemi multiutente, sono necessari meccanismi più sofisticati per regolare l’accesso e garantire che solo gli utenti autorizzati possano interagire con i dati.

10.4.1 Tipo di Accesso

Nei sistemi multiutente è necessario garantire la protezione dei file da accessi indesiderati, p.e., da utenti non autorizzati (nei sistemi senza accesso multiutente invece la protezione può non essere richiesta).

L’accesso controllato regola varie operazioni sui file in base al tipo di permessi. Operazioni come lettura, scrittura, esecuzione, aggiunta, cancellazione, elenco e modifica degli attributi possono essere regolate. Operazioni ad alto livello come il cambio nome, la copia e la modifica dei file possono essere implementate tramite chiamate di sistema a livello più basso e quindi ereditare la protezione di questi livelli. Ad esempio, una copia può essere realizzata con chiamate di read() quindi l’accesso in sola lettura garantisce la copia. È bene differenziare anche i livelli di protezione in base al contesto. Per esempio, un piccolo gruppo di ricerca potrebbe non richiedere gli stessi livelli di protezione di una grande rete aziendale.

10.4.2 Controllo degli accessi

L’approccio comune alla protezione è quello di implementare diversi livelli di accesso a un file in base all’identità dell’utente. Tipicamente, ogni file/directory è associato a una lista di controllo degli accessi (Access Control List, ACL) che specifica gli utenti e il tipo di accesso permesso. Quando un utente richiede accesso, il sistema controlla l’ACL. Se è consentito, l’accesso viene garantito, altrimenti viene negato.

Esistono due problemi con questo approccio:

Mantenere la lista per ogni file è faticoso, specialmente se non si conoscono gli utenti in anticipo
La dimensione di una entry diventa è ora di size variabile e la gestione dello spazio su disco diventa più complicata

Per semplificare la gestione, molti sistemi condensano la lunghezza della ACL implementando tre classificazioni degli utenti:

Proprietario: l’utente che ha creato il file è il proprietario
Gruppo: un insieme di utenti che condividono il file e necessitano di accessi simili
Altro: tutti gli altri utenti nel sistema

Il gruppo altro può anche essere sostituito col gruppo universo (tutti gli utenti). Quest’ultimo approccio, può essere combinato con ACL per fornire, quando necessario, un controllo degli accessi più specifico. Per far funzionare questo schema, i permessi vanno controllati. Ad esempio, nel sistema UNIX, i gruppi possono essere creati e modificati solo dal responsabile della struttura o da qualsiasi superutente e il controllo è garantito attraverso l’interazione umana.

Con questo tipo di protezione sono richiesti solo tre campi, organizzati tipicamente come collezioni di bit, ognuno che controlla diversi tipi di accesso (lettura, scrittura, esecuzione, per utente, gruppo, altro).

10.5 File mappati in memoria

La mappatura in memoria di un file consiste nel caricare blocchi di file nelle pagine della memoria centrale, evitando di accedere riga per riga al file attraverso le chiamate open(), read() and write(). Questo metodo può migliorare significativamente le prestazioni rispetto ai metodi tradizionali di accesso al disco.

La scrittura su disco di una pagina modificata non avviene subito, ma solamente quando il file viene chiuso, oppure regime di scarsità di spazio nella memoria centrale.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 13.

Interfaccia del file system

Fri, 03 May 2024 00:00:00 +0000

Il file system è essenziale nei s.o., fornendo archiviazione e accesso ai dati e ai programmi. È composto da file che memorizzano dati correlati e da una struttura a directory che organizza le informazioni sui file. La maggior parte dei file system risiede su dispositivi di archiviazione. In questa lezione discutiamo degli aspetti dei file, delle strutture delle directory, della condivisione dei file tra processi e utenti, e delle modalità di protezione dei file.

Aspetti base dei file

I file sono unità di memorizzazione logica delle informazioni che forniscono un’astrazione delle caratteristiche fisiche di archiviazione dei dati.

Concetto di file

I computer archiviano dati su diversi supporti, astratti dal s.o. per una visione uniforme. Dal punto di vista dell’utente, un file è la più piccola porzione di archiviazione logica secondaria. I dati non possono essere scritti su archiviazione secondaria a meno che non siano contenuti in un file. Essi comprendono programmi e informazioni, strutturati secondo le esigenze dell’utente. Le strutture dei file variano, adattandosi a tipi di contenuto come testo, codice sorgente o eseguibili. UNIX e s.o. simili sfruttano i file system per accedere ai dati di sistema. Le strutture dei file sono determinate dal loro tipo, facilitando l’uso da parte delle applicazioni. Consentono di memorizzare informazioni come programmi, numeri, testi, multimediali e altro ancora. Ogni tipo di file ha una struttura distinta, organizzata per usabilità ed efficienza. I file servono come metodo principale per gli utenti e le applicazioni per memorizzare e accedere ai dati. Il concetto di file è ampio, comprendendo sequenze di bit, byte, linee o record. I file system gestiscono le informazioni sui file e forniscono accesso attraverso processi, utenti e computer. Tra i vari tipi di file, abbiamo:

file di testo: sequenza di caratteri organizzati in linee (e eventualmente pagine).
file sorgente: sequenza di funzioni, ognuna delle quali è ulteriormente organizzata come dichiarazioni seguite da istruzioni eseguibili.
file eseguibile: sequenza di sezioni di codice che il loader può caricare in memoria ed eseguire.

Attributi dei file

I file sono denominati, tipicamente per comodità, con stringhe come example.c. La denominazione rende i file indipendenti dagli utenti e dai sistemi, consentendo una facile condivisione e manipolazione. I s.o. possono o meno differenziare tra caratteri maiuscoli e minuscoli nei nomi. Nonostante trasferimenti o modifiche, i file mantengono i loro nomi, facilitando la coerenza nell’accesso e gestione. Alcune informazioni che caraterizzano i file:

Nome: il nome simbolico del file è l’unica informazione conservata in forma user-readable
Identificatore: tag unico, di solito un numero, che identifica il file all’interno del file system. È il nome non-user-readable del il file
Tipo: necessario per i sistemi che supportano diversi tipi di file
Locazione: un puntatore a un dispositivo e alla posizione del file su tale dispositivo
Dimensione: la dimensione attuale del file (in byte, parole o blocchi) e eventualmente la dimensione massima consentita sono incluse in questo attributo
Protezione: le informazioni sul controllo degli accessi determinano chi può fare lettura, scrittura, esecuzione, e così via
Timestamp e identificazione dell’utente: queste informazioni possono essere conservate per la creazione, l’ultima modifica e l’ultimo utilizzo. Possono essere inoltre utili per la protezione, la sicurezza e il monitoraggio dell’uso

Operazioni sui file

Creare un file: consiste nel trovare spazio nel file system e fare un’entrata in una directory
Aprire un file: varie operazioni (tranne creare e eliminare) richiedono una chiamata open() di file, che restituisce un handle di file per il suo utilizzo
Scrivere un file: richiede di specificare un handle di file aperto e i dati da scrivere, aggiornando un puntatore di scrittura sequenziale
Leggere un file: richiede di specificare l’handle del file e la locazione di memoria per il blocco successivo, aggiornando un puntatore di lettura per letture sequenziali
Rilocamento all’interno di un file consiste nel riposizionamento del puntatore di locazione corrente del file, senza eseguire operazioni I/O. Questa operazione è nota anche come file seek
Eliminare un file: coinvolge la ricerca della directory per il file, il rilascio del suo spazio e la cancellazione o marcatura della sua voce di directory
Troncare un file: consente di cancellare i contenuti del file mantenendo gli attributi reimpostando la lunghezza del file a zero e rilasciando il suo spazio

Tipi di file

Quando si progetta un file system per un s.o., i tipi di file sono un aspetto cruciale per il suo corretto funzionamento. I s.o. riconoscono solo alcuni tipi di file che possono elaborare di conseguenza. I tipi di file sono spesso indicati da estensioni nei nomi dei file, aiutando gli utenti e i sistemi a identificare i tipi. Estensioni come .exe o .sh dettano le operazioni sui file (p.e. esecuzione). I programmi ricorrono alle estensioni per il riconoscimento dei tipi di file supportati, come .java per i file sorgente Java o .docx per i documenti di Microsoft Word.

UNIX utilizza un semplice codice noto come magic number all’inizio dei file per indicare il tipo di dati. Le estensioni dei nomi dei file in sono per convenienza dell’utente e non sono applicate dal sistema operativo, fornendo quindi suggerimenti sui contenuti dei file piuttosto che regole per le applicazioni.

Struttura dei file

I tipi di file possono anche indicare la struttura interna di un file e sono essenziali affinché il s.o. li comprenda e li elabori correttamente. Tuttavia, il supporto a più strutture di file può rendere il codice del s.o. ingombrante e complesso. D’altro canto quando un file viene codificato in una struttura non supportata dal s.o., si possono verificare problemi ed è necessario istruire il s.o. a non utilizzar il file incorrettamente. Alcuni s.o., come UNIX e Windows, impongono requisiti minimi per le strutture di file, supportando solo la struttura di file eseguibile per le funzionalità di base del sistema. È possibile definire altre strutture di file ed è compito delle applicazioni fornire il codice per interpretarle.

Struttura interna dei file

Il sistema operativo gestisce internamente le strutture dei file, spesso utilizzando un approccio basato su blocchi. L’I/O del disco funziona in blocchi di dimensioni fisse, che potrebbero non allinearsi perfettamente con i record logici. Per affrontare questo problema, i record logici vengono compattati in blocchi fisici, sia dal s.o. che dall’applicazione dell’utente. Ciò garantisce efficienza nello storage e recupero dei dati. Si può verificare, tuttavia, frammentazione interna a causa dello spazio sprecato nell’ultimo blocco, poiché i file vengono allocati in blocchi di dimensioni fisse. I diversi file system gestiscono la frammentazione interna in modo diverso, con dimensioni di blocco più grandi che portano a una maggiore frammentazione.

Metodi d’accesso

Accesso sequenziale

L’accesso sequenziale legge e scrive i dati in ordine, ed è comunemente utilizzato da editor e compilatori. Le operazioni di lettura fanno avanzare un puntatore di file e leggono la porzione successiva di dati, mentre le operazioni di scrittura aggiungono dati alla fine e regolano di conseguenza il puntatore di file. I file possono essere reimpostati all’inizio, e alcuni sistemi consentono di saltare avanti o indietro di un numero definito di record. Questo metodo di accesso funziona universalmente su dispositivi sequenziali e ad accesso casuale.

Accesso diretto

L’accesso diretto facilita la rapidità di lettura e scrittura di record (elementi logici) di lunghezza fissa, fondamentale per database e grandi set di dati. Le operazioni sui file includono read(n) e write(n) laddove n è il numero di blocco. I numeri di blocco sono codificati relativamente all’inizio del file e vengono tradotti in indirizzi fisici. Assumendo una lunghezza del record di $L$ byte La richiesta per un record $N$ si traduce in richieste di I/O per $L$ byte in posizione $L \cdot N$. Alcuni sistemi limitano l’accesso ai file sia sequenziale che diretto, determinato durante la creazione del file. La simulazione dell’accesso diretto su un file sequenziale è inefficiente a causa della sua struttura intrinseca.

Struttura delle directory

Le directory fungono da tabelle di simboli, traducendo i nomi dei file nei loro blocchi di controllo e offrendo vari schemi organizzativi. Queste strutture devono facilitare l’inserimento, la cancellazione, la ricerca e le operazioni di elenco delle voci. Quando si progetta un sistema di directory, è cruciale allineare la struttura con le operazioni di directory previste:

Ricerca di un file: le strutture delle directory dovrebbero supportare la ricerca efficiente di file specifici, potenzialmente includendo la corrispondenza di modelli per nomi di file correlati
Creazione di un file: è essenziale poter creare nuovi file e incorporarli nella struttura delle directory
Eliminazione di un file: i file dovrebbero essere eliminabili dalla directory quando non sono più necessari, potenzialmente portando a metodi di deframmentazione della directory
Elencamento di una directory: è necessario elencare tutti i file all’interno di una directory
Rinominazione di un file: i nomi dei file dovrebbero essere modificabili per riflettere le modifiche nei contenuti o nell’uso del file, potenzialmente influenzando la posizione nella struttura della directory
Attraversamento del file system: accedere a tutte le directory e i file all’interno di una struttura può essere necessario per scopi di backup, spesso raggiunto copiando i dati su supporti di archiviazione secondari o sul cloud per proteggersi da guasti del sistema

Directory a un livello

La struttura delle directory a livello singolo memorizza tutti i file in una sola directory, semplificando la gestione ma ponendo limitazioni quando il numero dei file aumenta o con più utenti. Ogni file deve avere un nome univoco. Anche per un singolo utente, gestire molti file su diversi sistemi può essere scoraggiante, evidenziando la necessità di strutture di directory più complesse.

Directory a due livelli

Nella struttura delle directory a due livelli, ogni utente ha una directory dei file utente (User File Directory, UFD), mentre la directory dei file principale (Master File Direcoty, MFD) indicizza le UFD degli utenti. Gli utenti possono avere file con nomi identici all’interno delle loro UFD. Un programma di sistema separato viene utilizzato per creare ed eliminare le UFD, di solito eseguibile dagli amministratori. Sebbene risolva i problemi di collisione dei nomi, isola gli utenti e complica l’accesso ai file tra loro. Per accedere ai file in un’altra directory dell’utente, si deve specificare sia il nome utente che il nome del file.

Directory con struttura ad albero

Estendere la struttura delle directory a un albero di altezza arbitraria consente agli utenti di creare sotto-directory, organizzando i file in modo più efficiente. Ogni file nel sistema ha un nome del percorso univoco all’interno di questa struttura ad albero. Le directory o le sotto-directory contengono insiemi di file o sotto-directory, con una root directory in cima. In molte implementazioni, i file e le directory vengono distinti attraverso l’utilizzo di un bit e il s.o. implementa il formato di file “directory” che viene gestito attraverso chiamate di sistema apposite. Di solito, ogni processo ha la propria directory corrente, contenente file rilevanti, ma è possibile usare una chiamata di sistema per cambiare directory. La directory iniziale di un utente viene impostata all’accesso. I sottoprocessi ereditano di solito la directory corrente del genitore.

Directory con grafo aciclico

La creazione di link, ovvero puntatori al file
La duplicazione del file. È necessario mantenere l’integrità dei dati tra le due copie

L’eliminazione di file condivisi in strutture a grafi aciclici è complessa e presenta tre problemi:

Quando un link viene eliminato bisogna decidere se rimuovere il file a esso associato
Quando un file viene eliminato gli eventuali link relativi a esso diventano pendenti (dangling) e puntano a una posizione vuota
Se dei nuovi dati vanno a occupare una posizione puntata da link pendenti, tali link punteranno a dei dati non corretti.

Per risolvere questi problemi, esistono due approcci:

Rimuovere il link senza eliminare il file a esso associato. Se il file stesso viene eliminato, possiamo:
- Cercare tutti i suoi link ed eliminarli. Questo approccio richiede di mantenere una struttura che elenchi i link al file
- Non eliminare i link. Nel momento in cui uno di questi link viene usato, si controlla che il file a cui puntano sia quello corretto. In caso contrario, viene lanciato un errore di accesso illegale a file.
In UNIX e Windows, i link vengono lasciati e sta all’utente controllare che se il file originale è stato eliminato o sostituito.
Mantenere il file finché tutti i suoi riferimenti non vengono cancellati. È possibile associare al file un contatore ai suoi riferimenti. Quando il contatore scende a $0$, il file può venire eliminato. Un garbage collector entra in funzione a intervalli periodici e controlla tutti i file, eliminandoli in caso il contatore sia a $0$. UNIX utilizza questo approccio con link non-simbolici (hard).

Infine, alcuni sistemi optano per vietare del tutto le directory o i collegamenti condivisi.

Directory con grafo generale

Protezione

Garantire la sicurezza delle informazioni in un sistema informatico comporta di occuparsi di aspetti quali affidabilità e protezione.

Tipo di Accesso

Controllo degli accessi

L’approccio comune alla protezione è quello di implementare diversi livelli l’accesso un file in base all’identità dell’utente. Tipicamente, ogni file/directory è associato a una lista di controllo degli accessi (Access Control List, ACL) che specifica gli utenti e il tipo di accesso permesso. Quando un utente richiede accesso, il sistema controlla l’ACL. Se è consentito, l’accesso viene garantito, altrimenti viene negato.

Esistono due problemi con questo approccio:

Mantenere la lista per ogni file è faticoso, specialmente se non si conoscono gli utenti in anticipo
La dimensione di una entry diventa è ora di size variabile e la gestione dello spazio su disco diventa più complicata

Per semplificare la gestione, molti sistemi condensano la lunghezza della ACL implementando tre classificazioni degli utenti:

Proprietario: l’utente che ha creato il file è il proprietario
Gruppo: un insieme di utenti che condividono il file e necessitano di accessi simili
Altro: tutti gli altri utenti nel sistema

File mappati in memoria

La scrittura su disco di una pagina modificata non avviene subito, ma solamente quando il file viene chiuso, oppure regime di scarsità di spazio nella memoria centrale.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 13.

Implementazione del file system

Wed, 08 May 2024 00:00:00 +0000

In questa lezione tratteremo gli aspetti comuni condivisi dai molteplici file system presenti nel mercato.

Struttura di un file system

Un file system fornisce un accesso conveniente ed efficiente allo storage. Il suo design richiede di:

Definire la struttura di un file
Creare algoritmi e strutture dati per la gestione efficiente di un file system

La struttura di un file system può essere definita a strati. Dal livello più alto (software) al più basso (hardware) abbiamo:

Programmi: richiedono ed elaborano dati (tramite la CPU)
File system logico: gestisce i metadati del file system, ovvero tutte le sue informazioni ad esclusione dei dati stessi. Include:
- La struttura a directory del file system
- I metadati dei file raggruppati in File Control Block (FCB) (inode nei file system UNIX). Nei FCB troviamo informazioni come la proprietà, i permessi e la locazione del file
Modulo di organizzazione file: gestisce i file e i loro blocchi logici (numerati da $0$/$1$ a $N$). Ne fa parte anche il gestore dello spazio libero che tiene traccia dei blocchi liberi e li fornisce all’occorrenza
File system di base: si occupa di inviare generiche istruzioni di lettura o scrittura ai dispositivi di memoria secondaria e di gestire cache e buffer per una gestione più efficiente dei trasferimenti di dati
Controllo I/O: consiste di driver di dispositivo e gestori di interrupt per trasferire l’informazione tra la memoria principale e quella secondaria. Il driver è un “traduttore” da istruzioni ad alto livello (p.e. recupera il blocco 123) a istruzioni per il controllore hardware.
Dispositivi di memoria secondaria: l’hardware preposto a salvare i dati permanentemente

Con una struttura a strati il codice viene minimizzato poiché, ad esempio, il codice del file system di base può essere utilizzato con altri file system.

Operazioni del file system

In questa sezione esploriamo le strutture e le operazioni coinvolte nell’implementazione delle operazioni del file system di open() e close().

Panoramica

Nell’implementazione del file system vengono utilizzate diverse strutture, che comprendono informazioni relative all’avvio del s.o., al conteggio totale dei blocchi, al conteggio e alle posizioni dei blocchi liberi, alla struttura delle directory e ai singoli file. Vediamole:

Blocco di controllo di avvio (boot control block): contiene informazioni necessarie all’avvio del s.o. in un volume. Se il disco non contiene un sistema operativo, tale blocco può essere vuoto
Blocco di controllo del volume (volume control block): memorizza dettagli del volume come conteggio e dimensione dei blocchi, conteggio e puntatori dei blocchi liberi
Struttura delle directory: usata per organizzare i file
Blocco di controllo del file (File Control Block, FCB): contiene dettagli del file e un identificatore univoco per l’associazione alla directory

L’informazione in-memoria serve sia per la gestione del file system che per il miglioramento delle prestazioni tramite caching. Viene caricata al momento del mount ed eliminata al dismount del volume. Può includere:

Tabella di mount: contiene dettagli su ciascun volume montato
Cache della struttura delle directory: memorizza informazioni sulle directory a cui si è avuto recentemente accesso
Tabella di sistema dei file aperti: contiene copie di FCB per file aperti
Tabella dei file aperti (per processo): contiene puntatori alle entry nella tabella dei file aperti dal processo
Buffer: memorizza temporaneamente blocchi del file system durante le operazioni di trasferimento dati

Per creare un file, il file system logico assegna un nuovo FCB e aggiorna di conseguenza la struttura della directory che lo conterrà. Alcuni s.o. trattano le directory in modo simile ai file, mentre altri le trattano separatamente. Il file system logico gestisce il mapping I/O alle posizioni dei blocchi di archiviazione, interagendo con il modulo di organizzazione dei file e il sistema di controllo I/O.

Utilizzo

Prima di poter eseguire operazioni di I/O, i file devono essere aperti. La chiamata open() passa il nome del file al file system logico, che verifica se il file è già aperto da un altro processo. In tal caso, crea una entry che punti alla tabella già esistente per ridurre l’overhead. Se il file non è già aperto, viene cercato nella struttura delle directory, spesso memorizzata nella cache in-memoria. Una volta trovato, il FCB viene copiato nella tabella di sistema dei file aperti e viene creato una entry per il processo. Quando un processo chiude il file, la sua entry viene rimossa e il conteggio delle aperture del file viene decrementato. I metadati aggiornati vengono scritti nuovamente sul disco quando tutti gli utenti chiudono il file. Le strutture del file system memorizzano informazioni nella cache in-memoria, ad eccezione dei blocchi di dati, per l’ottimizzazione delle prestazioni.

Realizzazione delle directory

In questa sezione esploriamo gli algoritmi di allocazione e gestione delle directory e il loro impatto sull’efficienza, sulle prestazioni e sulla affidabilità del file system.

Lista lineare

Un approccio di base all’implementazione delle directory prevede una lista lineare di nomi di file con puntatori ai blocchi di dati, che è semplice da programmare ma lenta nell’esecuzione. La creazione di un nuovo file richiede la ricerca nella directory per possibili file con lo stesso nome e l’aggiunta di una nuova entry alla fine. L’eliminazione di un file comporta la ricerca e il rilascio dello spazio allocato.

La ricerca lineare necessaria per trovare i file in questa configurazione può essere lenta. Molti s.o. utilizzano una cache per memorizzare le informazioni sulle directory che vengono accedute frequentemente. Utilizzare una lista ordinata consente una ricerca binaria, riducendo il tempo di ricerca, ma mantenere l’ordine può complicare la creazione e l’eliminazione dei file. Strutture dati più complesse come gli alberi bilanciati potrebbero alleviare questo problema.

Tabella hash

Un’altra struttura dati utilizzata per le directory dei file è la tabella hash, che combina una lista lineare con una struttura dati hash. La tabella hash calcola un valore dal nome del file, utilizzato per l’indicizzazione nella lista, riducendo significativamente il tempo di ricerca nella directory. L’inserimento e l’eliminazione sono relativamente semplici, tuttavia quando c’è una collisione (due file generano lo stesso hash), è necessario salvare la nuova entry nella prima posizione successiva libera (open hash). Le tabelle hash spesso hanno dimensioni fisse, con funzioni hash dipendenti da questa dimensione. Ad esempio, se una tabella contiene $64$ entry e viene aggiunto un nuovo file, la tabella deve essere ingrandita, rendendo necessaria una nuova funzione hash e la riorganizzazione delle entry. In alternativa, si può utilizzare una tabella hash con overflow concatenato, dove ogni entry hash contiene una lista per ospitare le collisioni. Anche se le ricerche possono essere più lente a causa dell’attraversamento delle liste, questo metodo è generalmente più veloce di una ricerca lineare attraverso l’intera directory.

Metodi di allocazioni

La natura ad accesso diretto dello storage secondario consente un’implementazione flessibile dei file. È cruciale allocare lo spazio in modo efficiente per un accesso rapido quando sono memorizzati più file su un singolo dispositivo. Tre metodi principali - contiguo, collegato e indicizzato - sono comunemente utilizzati, ciascuno con vantaggi e svantaggi unici.

Allocazione contigua

Con l’allocazione contigua i blocchi di un file vengono salvati uno vicino all’altro. Salvare un file richiede quindi la definizione dell’indirizzo di partenza e della sua lunghezza, facilitandone l’accesso. Questo metodo è semplice da implementare ma richiede attenzione per via della frammentazione esterna. Diverse strategie, come il first-fit e il best-fit, cercano di alleviare il problema.

Per mitigare ulteriormente il problema della frammentazione, un approccio consiste nel copiare l’intero file system su un altro dispositivo, e ricopiarlo sul dispositivo originale compattandolo. Il processo può tuttavia richiedere molto tempo, soprattutto per dispositivi di grandi dimensioni. Alcuni s.o. richiedono che l’operazione sia fatta offline quando il dispositivo non è montato. Inoltre, determinare lo spazio richiesto per un file può essere difficile, portando potenzialmente a una sottostima e successivi errori di allocazione. Se lo spazio allocato è insufficiente, i programmi possono terminare o richiedere esecuzioni ripetute. In alternativa, trovare un buco contiguo più grande e spostare i contenuti del file può alleviare il problema, anche se con una complessità temporale aumentata. Nonostante queste sfide, i sistemi moderni mirano a eseguire la deframmentazione online durante le operazioni regolari, anche se con potenziali penalità sulle prestazioni.

L’allocazione contigua richiede inoltre di sapere in anticipo la dimensione di un file, per preallocare lo spazio richiesto. La preallocazione può portare a frammentazione interna. Per mitigare questo problema, i s.o. possono adottare un approccio di allocazione contigua modificato, allocando inizialmente un blocco di spazio e aggiungendo estensioni se necessario. Ogni estensione viene registrata e collegata alla precedente. Anche se a volte gli utenti possono impostare le dimensioni dell’estensione, impostazioni errate possono causare inefficienze. Estensioni grandi possono comunque causare frammentazione interna, mentre dimensioni variabili nell’estensione possono portare a frammentazione esterna.

Allocazione concatenata

Con questo tipo di allocazione i blocchi di cui è composto un file non sono necessariamente contigui e formano una lista concatenata. La directory si salva il puntatore al blocco iniziale e finale del file. Questo metodo presenta tre svantaggi principali:

L’accesso al file risulta essere sequenziale, poiché è necessario seguire i puntatori per raggiungere la posizione di lettura richiesta
Un altro svantaggio è il maggiore peso di un file in memoria, dovuto al salvataggio dei puntatori. Per ovviare a questo problema i blocchi vengono spesso raggruppati in cluster e l’allocazione avviene per cluster anziché per blocco. Questa tecnica aumenta la frammentazione interna.
Se un pointer viene danneggiato o perso il s.o. può avere dei comportamenti imprevedibili. Per alleviare il problema è possibile utilizzare liste doppiamente concatenate o salvare il nome del file e il numero di blocco in ogni file per identificare la sua appartenenza.

File Allocation Table (FAT) di MS-DOS utilizza una variante di questo sistema in cui una tabella (FAT appunto) mappa il numero di un blocco al puntatore del blocco successivo.

Allocazione indicizzata

Con questo tipo di allocazione viene riservato un blocco indice che contiene tutti i puntatori ai blocchi. Questo metodo fornisce indicizzazione diretta senza soffrire di frammentazione esterna, tuttavia è necessario allocare un intero blocco per contenere l’indice. Nel caso di file piccoli, lo spazio allocato per l’indice è eccessivo. Tra i vari modi di gestire l’indice troviamo:

Schema concatenato: un blocco indice corrisponde a un blocco dello storage. In caso di grandi file, l’indice può essere spezzettato in vari blocchi collegati da puntatori
Indice multilivello: l’indice viene spezzato in più livelli
Schema combinato: un’alternativa utilizzata nei sistemi UNIX. La maggior parte dei puntatori punta a dei blocchi di dati, mentre una parte più piccola punta a blocchi contenenti puntatori

Gestione dello spazio libero

Per gestire lo spazio libero viene utilizzata una struttura chiamata lista dello spazio libero. Tale struttura tiene traccia di tutti i blocchi liberi e li fornisce su richiesta del s.o. Nonostante il nome non è sempre implementata come una lista. Vediamo alcune implementazioni.

Vettore di bit

Spesso, viene utilizzata questa implementazione che consiste nel gestire una lista di bit, uno per blocco. Un bit a $0$ indica che il blocco corrispondente è libero, mentre un bit a $1$ indica un blocco occupato. Lo svantaggio principale è che l’accesso alla struttura può essere dispendioso a meno che l’intero vettore non venga tenuto in memoria, con conseguenti difficoltà nel caso di dispositivi di grandi dimensioni.

Lista concatenata

Ogni blocco libero contiene il puntatore al blocco libero successivo. Inoltre, è possibile fare il caching dei primi blocchi per avere un accesso veloce. L’approccio è inefficiente poiché lo scorrimento della lista richiede molte operazioni I/O, ma fortunatamente è un’operazione poco frequente.

Raggruppamento

In questo caso, il primo blocco libero contiene gli indirizzi dei primi $n$ blocchi liberi. L’ultimo blocco di questo primo gruppo, contiene gli indici degli $n$ blocchi liberi successivi e così via.

Conteggio

È una variante del caso precedente in cui un blocco libero punta a un blocco successivo, garantendo che gli $n$ blocchi contigui siano liberi anch’essi.

Recupero dati

Un disastro di sistema può causare una perdita di dati o interrompere un processo di modifica del file system, generando così inconsistenze. Per tali motivi è bene adottare delle misure di prevenzione dell’integrità dei dati.

Controllo della consistenza

Prima di tutto, è importante monitorare la consistenza dei dati. Per fare ciò viene avviato un programma che controlla un bit di stato che viene impostato a uno ogniqualvolta è in corso un’operazione di modifica dei metadati di un file. Se tale operazione viene per qualche motivo interrotta prima di completare, il bit rimane impostato a $1$ e il programma di monitoraggio è così in grado di identificare un problema di integrità dei dati. A seguire, confronta i metadati con lo stato del programma per provare a correggere eventuali problemi.

File system basati su log

Questo sistema consiste nell’utilizzare un log, ovvero un buffer circolare in cui il s.o. scrive le operazioni sui metadati da svolgere, chiamate transazioni. Le transazioni vengono completate in maniera asincrona dal file system che si occupa di portarle a termine. Se il sistema si interrompe bruscamente, al suo riavvio, viene ripresa la lettura delle istruzioni dal buffer, minimizzando così i potenziali problemi di integrità derivanti.

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 14.

11 Implementazione del file system

Wed, 17 Apr 2024 00:00:00 +0000

In questa lezione tratteremo gli aspetti comuni condivisi dai molteplici file system presenti nel mercato.

11.1 Struttura di un file system

Un file system fornisce un accesso conveniente ed efficiente allo storage. Il suo design richiede di:

Definire la struttura di un file
Creare algoritmi e strutture dati per la gestione efficiente di un file system

La struttura di un file system può essere definita a strati. Dal livello più alto (software) al più basso (hardware) abbiamo:

Programmi: richiedono ed elaborano dati (tramite la CPU)
File system logico: gestisce i metadati del file system, ovvero tutte le sue informazioni ad esclusione dei dati stessi. Include:
- La struttura a directory del file system
- I metadati dei file raggruppati in File Control Block (FCB) (inode nei file system UNIX). Nei FCB troviamo informazioni come la proprietà, i permessi e la locazione del file
Modulo di organizzazione file: gestisce i file e i loro blocchi logici (numerati da $0$/$1$ a $N$). Ne fa parte anche il gestore dello spazio libero che tiene traccia dei blocchi liberi e li fornisce all’occorrenza
File system di base: si occupa di inviare generiche istruzioni di lettura o scrittura ai dispositivi di memoria secondaria e di gestire cache e buffer per una gestione più efficiente dei trasferimenti di dati
Controllo I/O: consiste di driver di dispositivo e gestori di interrupt per trasferire l’informazione tra la memoria principale e quella secondaria. Il driver è un “traduttore” da istruzioni ad alto livello (p.e. recupera il blocco 123) a istruzioni per il controllore hardware.
Dispositivi di memoria secondaria: l’hardware preposto a salvare i dati permanentemente

Con una struttura a strati il codice viene minimizzato poiché, ad esempio, il codice del file system di base può essere utilizzato con altri file system.

11.2 Strutture e operazioni del file system

In questa sezione esploriamo le strutture e le operazioni coinvolte nell’implementazione delle operazioni del file system di open() e close().

11.2.1 Strutture

Nell’implementazione del file system vengono utilizzate diverse strutture per il suo avvio e la sua gestione. Vediamole:

Blocco di controllo di avvio (boot control block): contiene informazioni necessarie all’avvio del s.o. in un volume. Tipicamente il programma di bootstrap, situato in una ROM, istruisce di leggere il programma di bootstrap completo nel boot control block. Se il disco non contiene un sistema operativo, tale blocco può essere vuoto.
Blocco di controllo del volume (volume control block): memorizza dettagli del volume come il conteggi/dimensione dei blocchi, e il conteggio/puntatori dei blocchi liberi.
Struttura delle directory: usata per organizzare logicamente i file.
Blocco di controllo del file (File Control Block, FCB): contiene dettagli del file e un identificatore univoco per l’associazione alla directory.

Tabella di mount: contiene dettagli su ciascun volume montato.
Cache della struttura delle directory: memorizza informazioni sulle directory a cui si è avuto recentemente accesso.
Tabella di sistema dei file aperti: contiene copie di FCB per file aperti.
Tabella dei file aperti (per processo): contiene puntatori alle entry nella tabella dei file aperti dal processo.
Buffer: memorizza temporaneamente blocchi del file system durante le operazioni di trasferimento dati.

11.2.2 Utilizzo

11.3 Realizzazione delle directory

In questa sezione esploriamo gli algoritmi di allocazione e gestione delle directory e il loro impatto sull’efficienza, sulle prestazioni e sulla affidabilità del file system.

11.3.1 Lista lineare

Un approccio di base all’implementazione delle directory prevede una lista lineare di nomi di file con puntatori ai blocchi di dati, che è semplice da programmare ma lenta nell’esecuzione. La creazione di un nuovo file richiede la ricerca nella directory per possibili file con lo stesso nome e l’aggiunta di una nuova entry al fine. L’eliminazione di un file comporta la ricerca e il rilascio dello spazio allocato.

11.3.2 Tabella hash

Un’altra struttura dati utilizzata per le directory dei file è la tabella hash, che combina una lista lineare con una struttura dati hash. La tabella hash calcola un valore dal nome del file, utilizzato per l’indicizzazione nella lista, riducendo significativamente il tempo di ricerca nella directory. L’inserimento e l’eliminazione sono relativamente semplici, tuttavia quando c’è una collisione (due file generano lo stesso hash), è necessario salvare la nuova entry nella prima posizione successiva libera (open hash). Le tabelle hash spesso hanno dimensioni fisse, con funzioni hash dipendenti da questa dimensione. Ad esempio, se una tabella contiene 64 entry e viene aggiunto un nuovo file, la tabella deve essere ingrandita, rendendo necessaria una nuova funzione hash e la riorganizzazione delle entry. In alternativa, si può utilizzare una tabella hash con overflow concatenato, dove ogni entry hash contiene una lista per ospitare le collisioni. Anche se le ricerche possono essere più lente a causa dell’attraversamento delle liste, questo metodo è generalmente più veloce di una ricerca lineare attraverso l’intera directory.

11.4 Metodi di allocazioni

11.4.1 Allocazione contigua

Con l’allocazione contigua i blocchi di un file vengono salvati uno vicino all’altro. Salvare un file richiede quindi la definizione dell’indirizzo di partenza e della sua lunghezza, facilitandone l’accesso. Questo metodo è semplice da implementare ma richiede attenzione per via della frammentazione esterna. Diverse strategie, come first-fit e il best-fit, possono alleviare il problema.

Per mitigare ulteriormente il problema della frammentazione, un approccio consiste nell’eseguire la deframmentazione ovvero copiare l’intero file system su un’altra zona di memoria, e ricopiarlo sul dispositivo originale compattandolo. Il processo può tuttavia richiedere molto tempo, soprattutto per dispositivi di grandi dimensioni. Alcuni s.o. richiedono che l’operazione sia fatta offline quando il dispositivo non è montato. Inoltre, determinare con accuratezza lo spazio richiesto per un file può essere difficile, portando potenzialmente a una sottostima e successivi errori di allocazione. Se lo spazio allocato è insufficiente, i programmi possono dover terminare o richiedere esecuzioni ripetute. In alternativa, è possibile trovare un buco contiguo più grande e spostare i contenuti del file, aumentando tuttavia la complessità temporale. Nonostante queste sfide, i sistemi moderni mirano a eseguire la deframmentazione online durante le operazioni regolari, anche se ciò può portare a un peggioramento delle prestazioni complessive.

11.4.2 Allocazione concatenata

L’accesso al file è sequenziale, poiché è necessario seguire i puntatori per raggiungere la posizione di lettura richiesta
Il file ha maggiori dimensioni in memoria, per via del salvataggio dei puntatori. Per ovviare a questo problema i blocchi vengono spesso raggruppati in cluster e l’allocazione avviene per cluster anziché per blocco. Questa tecnica aumenta la frammentazione interna.
Se un pointer viene danneggiato o il s.o. viene perso può avere dei comportamenti imprevedibili. Per alleviare il problema, è possibile utilizzare liste doppiamente concatenate o salvare il nome del file e il numero di blocco in ogni blocco per identificare la sua appartenenza.

File Allocation Table (FAT) di MS-DOS utilizza una variante di questo sistema in cui una tabella (FAT appunto) mappa il numero di un blocco al puntatore del blocco successivo.

11.4.3 Allocazione indicizzata

Schema concatenato: un blocco indice corrisponde a un blocco dello storage. In caso di grandi file, l’indice può essere spezzettato in vari blocchi collegati da puntatori.
Indice multilivello: l’indice viene spezzato in più livelli.
Schema combinato: un’alternativa utilizzata nei sistemi UNIX. La maggior parte dei puntatori punta a dei blocchi di dati, mentre una parte più piccola punta a blocchi contenenti puntatori.

11.5 Gestione dello spazio libero

11.5.1 Vettore di bit

11.5.2 Lista concatenata

Ogni blocco libero contiene il puntatore al blocco libero successivo. Inoltre, è possibile fare il caching dei primi blocchi per avere un accesso veloce. L’approccio presenta inefficienze nello scorrimento della lista poiché richiede molte operazioni I/O, tuttavia tale operazione è poco frequente.

11.5.3 Raggruppamento

11.5.4 Conteggio

È una variante che assume che spesso i blocchi liberi siano contigui tra loro. In questo caso, è possibile salvare l’indirizzo del primo blocco libero e un intero $n$ che indica i blocchi liberi contigui a esso.

11.6 Recupero dati

11.6.1 Controllo della consistenza

11.6.2 File system basati su log

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 14.

12 Sistemi I/O

Mon, 22 Apr 2024 00:00:00 +0000

Oltre all’elaborazione tramite CPU, l’altro compito principale di un elaboratore è l’Input/Output (I/O). L’I/O è essenziale per attività come la navigazione in Internet o la modifica di un file. Il ruolo del s.o. nell’I/O è quello di gestire e controllare i dispositive le loro operazioni. In questa sezione discutiamo dei principi di funzionamento dei dispositivi I/O.

La varietà dei dispositivi I/O nella loro funzione e nella loro velocità richiede a sua volta una varietà di metodi per la loro gestione, chiamata sottosistema I/O. Il sottosistema I/O gestisce la complessità dei dispositivi, separandola dal kernel. Se da un lato c’è una progressiva standardizzazione delle interfacce hardware e software, dall’altro c’è una sempre crescente varietà di dispositivi I/O che porta a sfide nella loro integrazione. Per affrontare questo problema, il kernel si interfaccia a un dispositivo I/O tramite un driver, ovvero un’interfaccia di accesso uniforme che incapsula i dettagli del dispositivo stesso.

12.1 Hardware di I/O

Introduciamo alcune definizioni legate all’hardware I/O:

Porta: il punto di connessione attraverso il quale un dispositivo comunica con l’hardware I/O tramite segnali, via-cavo o wireless.
Bus: un insieme di cavi di connessione condiviso da più dispositivi. L’utilizzo di un bus richiede un protocollo di utilizzo dei cavi e dei messaggi che possono essere inviati. I bus variano in base ai metodi di segnalazione, velocità, throughput e metodi di connessione.
- Bus PCIe: il bus che collega il sottosistema processore-memoria a dispositivi veloci (p.e. il monitor). PCIe trasmette dati su uno o più “corsie (lanes)”, delle connessioni full-duplex per la trasmissione dei dati.
- Bus di espansione: il bus che collega tra di loro dispositivi più lenti come tastiere e porte USB. Questo bus può essere poi connesso al bus PCIe tramite un’interfaccia apposita.
- Bus SAS: un bus che può essere usato per la connessione di memorie di massa. SAS sta per serial-attached SCSI (SCSI, è un’interfaccia di connessione). Il bus in questo caso viene connesso tramite un controller SAS.
Controller: è un insieme di componenti elettronici che gestisce una porta, un bus o un dispositivo.
- Serial-port controller: un controller piuttosto semplice costituito da un chip che gestisce i segnali inviati alla porta di un dispositivo.
- Fibre Channel (FC) bus controller: un controller complesso usato spesso nei data center. Viene implementato spesso con un circuito stampato (host bus adapter) che si connette a un bus del computer.

12.1.1 Comunicazione con l’I/O

Esistono due approcci principali per comunicare con l’I/O.

Registri specializzati: Il controller I/O possiede dei registri per la comunicazione col processore di dati e segnali di controllo (comandi).
I/O mappato in memoria: I registri corrispondono a indirizzi nella memoria principale. Il processore utilizza le normali routine di trasferimento dati.

Un dispositivo può implementare entrambi i metodi. In passato, un controller per la grafica a schermo possedeva dei registri specializzati per operazione di gestione di base e una zona in memoria per tenere l’output dello schermo. Oggigiorno, molte operazioni I/O sono mappate in memoria.

Il controllo del dispositivo I/O di solito coinvolge quattro registri: dati-in e dati-out, stato, controllo.

Registro di dati-in: letto dall’host per ricevere input.
Registro di dati-out: scritto dall’host per inviare output.
Registro di stato: contiene bit che indicano stati come il completamento di un comando, la disponibilità di dati e gli errori del dispositivo.
Registro di controllo: scritto dall’host per avviare comandi o modificare modalità del dispositivo, come il tipo di comunicazione, il controllo di parità, lunghezza della parola, o selezione della velocità di comunicazione.

I registri di dati sono solitamente di dimensioni comprese tra 1-4 byte. Alcuni controller incorporano chip FIFO, che estendono la capacità del controller memorizzando più byte di dati di input o output.

12.1.2 Polling

Il protocollo di interazione tra un host e un controller può essere complesso, ma il concetto base è semplice. Per esempio, consideriamo uno scenario in cui vengono utilizzati 2 bit per gestire la relazione produttore-consumatore. Il controller comunica il suo stato tramite un bit busy in un registro status, impostandolo quando è occupato e cancellandolo quando è pronto per il prossimo comando. L’host interagisce attraverso un bit command-ready in un registro command, impostandolo quando un comando è pronto per l’esecuzione. Questo consente una comunicazione coordinata tra l’host e il controller come segue:

L’host controlla continuamente il bit di busy finché non diventa 0.
L’host imposta il bit di scrittura in command e invia un byte al registro data-out.
L’host imposta il bit command-ready.
Dopo aver rilevato che command-ready è stato impostato, il controller imposta il bit busy.
Il controller esamina command, identifica il comando di scrittura, recupera il byte da data-out ed esegue l’operazione di I/O sul dispositivo.
Successivamente, il controller cancella command-ready, imposta a 0 il bit errore dentro status per indicare un’operazione di I/O del dispositivo riuscita e cancella il bit busy per indicare il completamento.

L’host monitora costantemente lo status register finché il bit busy non viene re-impostato, un metodo noto come attesa attiva (busy-waiting) o polling. È un approccio utile per operazioni veloci, ma se il polling va a vuoto per molti cicli di CPU, è preferibile il meccanismo di interrupt.

12.1.3 Interrupt

È necessario poter posticipare la gestione delle interruzioni durante fasi critiche di elaborazione.
È necessario un meccanismo efficiente per passare il controllo al giusto gestore degli interrupt senza interrogare tutti i dispositivi.
Sono richiesti interrupt multilivello per distinguere tra interrupt ad alta e bassa priorità e rispondere di conseguenza.
Le istruzioni devono essere in grado di richiamare direttamente l’attenzione del s.o. per attività come i fault di pagina e gli errori, che vengono gestiti tramite trap.

Nei system call, gli interrupt software, o trap, facilitano la comunicazione tra le applicazioni utente e il kernel. Questi interrupt hanno una priorità inferiore rispetto agli interrupt dei dispositivi. Inoltre, gli interrupt gestiscono il flusso di controllo del kernel, dando priorità a compiti come il completamento delle letture dal disco.

12.1.4 Accesso diretto alla memoria

Per trasferimenti efficienti di grandi quantità di dati, come quelli dei dischi rigidi è possibile utilizzare i controller di accesso diretto alla memoria (Direct Memory Access, DMA) che gestiscono autonomamente i trasferimenti di dati, senza l’utilizzo della CPU. L’host inizializza il DMA scrivendo un blocco di comandi in memoria, dove viene specificata la sorgente, e la destinazione dei dati e il conteggio dei byte da trasferire. La tecnica di scatter-gather consente trasferimenti complessi tramite un singolo comando.

Gli attuali sistemi operativi impiegano la mappatura della memoria per trasferimenti I/O diretti tra dispositivi e spazio degli indirizzi utente, migliorando le prestazioni.

12.2 Interfaccia di applicazione I/O

In questa sezione discutiamo delle interfacce e delle schematizzazioni utilizzate dai s.o. per trattare i dispositivi I/O in maniera uniforme.

I produttori di dispositivi possono invece:

Sviluppare un dispositivo per essere compatibile con un’interfaccia di controllore già presente (p.e. SATA, per i dischi)
Scrivere driver di dispositivo per interfacciarsi con i s.o. più popolari. Sfortunatamente ogni s.o. ha i propri standard per i driver di interfaccia.

Alcune scelte nel protocollo di comunicazione dei dispositivi:

Trasferimento a flusso di caratteri o a blocchi: un dispositivo può trasferire i byte uno ad uno oppure a gruppi.
Accesso sequenziale o diretto: un dispositivo può trasferire i dati seguendo un ordine fisso oppure puntando a posizioni non necessariamente contigue.
Sincrono o asincrono: un dispositivo può trasferire i dati in coordinamento con altri aspetti del sistema oppure con tempi di risposta variabili, non sincronizzati agli eventi del s.o.
Condiviso o dedicato: un dispositivo può essere utilizzato da molti processi contemporaneamente oppure da un solo processo alla volta.
Velocità di esecuzione: i dispositivi hanno velocità che spaziano da pochi byte al secondo a diversi gigabyte al secondo.
Read-write, read-only o write-once: alcuni dispositivi supportano la scrittura e la lettura, mentre altri solo una delle due operazioni. Inoltre in alcuni dispositivi la scrittura può essere effettuata solo una volta e il dato diventa read only, dopo.

Molti s.o. hanno un meccanismo di escape (o backdoor) che permette alle applicazioni di passare comandi arbitrari direttamente ai driver.

12.2.1 Dispositivi con trasferimento a blocchi e a caratteri

La tastiera, il mouse o il modem sono un esempi di interfaccia per dispositivi a caratteri (character-device interface). Le chiamate di sistema leggono o inseriscono un carattere alla volta.

12.2.2 I dispositivi di rete

12.2.3 Clock e timer

I clock e i timer forniscono le seguenti tre funzioni:

Danno il tempo corrente
Danno il tempo rimasto
Impostano delle deadline per emettere un evento in un istante di tempo prefissato

12.2.4 I/O asincrono e non bloccante

Possiamo dividere le chiamate a sistema in tre categorie:

I/O bloccante: una volta effettuata la chiamata, il thread chiamante attende la sua esecuzione e riceve il risultato dell’operazione di I/O. Spesso le chiamate I/O non sono bloccanti, poiché i dispositivi I/O hanno tempi imprevedibili, tuttavia il s.o. fornisce anche la possibilità di avere chiamate bloccanti poiché sono più semplici da gestire
I/O non bloccante: una volta effettuata la chiamata, questa ritorna velocemente. Il risultato è il numero di byte che sono stati trasferiti (tutti, una parte o nessuno). Un esempio di processo che richiede I/O non bloccante è un’interfaccia utente che processa indipendentemente l’input da mouse e da tastiera mentre visualizza gli output sul monitor
I/O asincrono: una volta effettuata la chiamata, questa ritorna immediatamente, senza il risultato, che viene computato completamente ma in futuro

12.2.5 I/O vettorizzato

Alcuni s.o. permettono di effettuare molteplici operazioni I/O attraverso un’unica chiamata a sistema.

12.3 Sottosistema di I/O del kernel

I kernel forniscono vari servizi relativi all’I/O, raggruppati nel sottosistema I/O. Vediamoli.

12.3.1 Scheduling I/O

12.3.2 Buffering

Un buffer è un’area di memoria che salva i dati in trasferimento tra due dispositivi e o tra un dispositivo e un’applicazione. Il buffering viene effettuato per tre ragioni:

Gestire lo squilibrio tra la velocità di produzione e di consumo dei dati. Per esempio, quando è necessario scrivere in una memoria secondaria un messaggio proveniente da Internet, è possibile programmare due buffer nella memoria principale. La rete inizia a trasmettere dati in un buffer. Quando questo è pieno la rete scrive sul secondo buffer, mentre il primo viene svuotato in memoria secondaria, e così via, finché il messaggio completo non viene salvato. Questo metodo è chiamato double buffering
Gestire lo squilibrio tra le dimensioni delle unità di trasferimento. Per esempio, in una rete, un messaggio da inviare viene frammentato in pacchetti piccoli che vengono ricevuti in buffer di destinazione per poi essere riassemblati
Gestire la semantica di copia per applicazioni I/O. Nel caso un’applicazione voglia scrivere nella memoria secondaria un buffer di dati prodotti, deve assicurarsi che il buffer non cambi durante la copia. Per questo motivo, è possibile creare un buffer kernel che operi la copia mentre il buffer dell’applicazione continua a produrre dati.

12.3.3 Caching

12.3.4 Spooling

12.3.5 Gestione degli errori

12.3.6 Protezione I/O

References

A. Silberschatz, P. B. Galvin, G. Gagne, Sistemi Operativi. Concetti ed Esempi, Decima edizione. Ch. 12.