Appunti Sistemi operativi - parte 1

Sommario

• Lezione 1 -> pag 2
• Lezione 2 -> pag 24
• Lezione 3 -> pag 48
• Lezione 4 -> pag 75
• Lezione 5 -> pag 97
• Lezione 6 -> pag 117
• Lezione 7 -> pag 129
• Lezione 8 -> pag 181
• Lezione 9 -> pag 205
• Lezione 10 -> pag 232
• Lezione 11 -> pag 271
• Lezione 12 -> pag 310
• Lezione 13 -> pag 336
• Lezione 14 -> pag 364
• Lezione 15 -> pag 385
• Lezione 16 -> pag 407
• Lezione 17 -> pag 433
• Lezione 18 -> pag 453
• Lezione 19 -> pag 475
• Lezione 20 -> pag 511
• Lezione 21 -> pag 528
• Lezione 22 -> pag 564
• Lezione 23 -> pag 598
• Lezione 24 -> pag 630
• Lezione 25 -> pag 662
• Lezione 26 -> pag 703
• Lezione 27 -> pag 739
• Lezione 28 -> pag 775
• Lezione 29 -> pag 809
• Lezione 30 -> pag 817
• Lezione 31 -> pag 861
• Lezione 32 -> pag 902
• Lezione 33 -> pag 950

Lezione 1

Il SO fornisce delle astrazioni e permette di scrivere dei programmi più efficienti. La programmazione concorrente è la capacità del SO di gestire la concorrenza e disciplinare l'accesso alle risorse da parte dei processi.

Un SO dà un accesso sicuro a tutte le risorse hardware, dove per sicuro si intende che se ad esempio un processo richiede l'accesso in memoria, questo accesso avverrà prima o poi e non ci saranno interferenze con altri processi. È il SO che in qualche modo fornisce le astrazioni ai programmi in esecuzione.

L'interfaccia per le system call è un'interfaccia dove ogni richiesta di accesso ad una risorsa hardware viene fatta attraverso una chiamata di sistema che al programmatore si presenta come una normale funzione di libreria (include iostream). La system call è una chiamata che deve essere processata dal SO e quindi è il SO che deve eseguire la richiesta per conto del processo. Ad esempio, quando invochiamo una f.open scatta questa system call che chiede al SO di aprire il file, la routine della open non sta nella libreria ma sta all'interno del SO che per conto del processo che l’ha evocata aprirà il file.

Tutti i programmi che richiedono accesso ad una risorsa hardware lo fanno attraverso la chiamata di sistema che è una chiamata che richiede al SO un'operazione ed il SO la esegue per conto del processo; il codice della funzione per la quale parte la system call non risiede nel processo ma all'interno del SO, viene quindi eseguito nel SO per conto del processo.

Il SO deve gestire le risorse hardware e deve fornire le astrazioni ai processi. Le risorse più importanti sono la CPU e quindi esiste un modulo che prende il nome di process management, il cui nome sta appunto per gestione dei processi, abbiamo poi un modulo per la gestione della memoria che prende il nome di memory management, abbiamo poi il file system che gestisce i file e I/O management che gestisce i dispositivi di input e output.

I SO nel tempo sono evoluti seguendo quello che è stato lo sviluppo nel tempo dell'hardware. I MIPS sono milioni di istruzioni per secondo che vengono eseguite da ogni singolo core del processore. Il costo di un processore viene anche ad essere misurato per il numero di operazioni su interi e questo costo è rappresentato nel secondo campo della tabella. Per quanto riguarda il fattore migliorativo dei processori abbiamo che tale fattore risulta essere molto piccolo in quanto andando ad aumentare l'indirizzamento un fattore di 2 ancora risulta essere più che sufficiente. L'evoluzione quindi risulta essere guidata da fattori migliorativi.

Ad oggi un SO ancora non riesce a sfruttare a pieno quelle che sono le migliorie offerte dallo sviluppo tecnologico dell'hardware. Alcune novità ad esempio delle CPU Intel di 10^° generazione che presentano algoritmi di consistenza della cache L1 che aiutano i compilatori non vengono sfruttate dai SO; anche la capacità di parallelismo che hanno questi processori non vengono ad essere sfruttate. Esiste quindi un GAP tra le caratteristiche avanzate dell'hardware e quello che poi un SO può effettivamente sfruttare dell'hardware stesso, questo ha portato oggi ad orientarsi verso un'architettura di processori ARM che sono dei processori molto più semplici e molto più economici rispetto ad esempio ai processori Intel che risultano essere sì più performanti ma non vengono sfruttati a pieno dagli odierni SO.

Storicamente abbiamo che negli anni 80 si andava a codificare un programma in una scheda codificata che veniva inserita in un sistema di tipo Batch che è un sistema che elabora a lotti e dopo un giorno si ottenevano i risultati dati dall'esecuzione. Con lo sviluppo dell'hardware i sistemi passarono verso la tipologia di sistemi multi programmati cioè dei sistemi che permettevano l'esecuzione di più programmi rispetto ai mono programmati come MSDOS dove veniva offerta un'interfaccia testuale come il prompt di Windows ed era possibile eseguire un processo alla volta. Negli anni 90 cominciarono ad apparire i primi sistemi multi programmati. I sistemi sono poi evoluti in sistemi di tipo Time Sharing dove abbiamo dei bassi tempi di risposta; tali sistemi sono dei sistemi che cercano di avere più processi ma di andare a ridurre quelli che sono i tempi di risposta. Dai sistemi Time Sharing hanno poi origine tutti i SO moderni e quindi PC, Mobile Computing ecc. N.B I sistemi Time Sharing sono quindi intesi come sistemi a condivisione di tempo.

All'inizio il SO era un programmino molto semplice che aveva un piccolo caricatore di programmi (loader), cioè un programma che serviva a caricare in memoria altri programmi e poi aveva una libreria di procedure comuni. Nel MSDOS era presente ad esempio un caricatore semplice che quando si andava a digitare a linea di comando il nome del programma il caricatore andava ad allocare in memoria quel programma e poi erano presenti una serie di comandi residenti in memoria e caricati nel file command.com. Questi sistemi avevano un grosso svantaggio che era quello di una bassa percentuale di utilizzo delle risorse. La percentuale di utilizzo di una CPU viene ad essere definita come il rapporto tra il tempo di effettivo utilizzo della risorsa fratto il tempo di osservazione della risorsa stessa, dove con risorsa intendiamo la CPU.

Consideriamo un piccolo esempio dove abbiamo una fase di lettura ed inizializzazione da un file alla quale segue una fase di esecuzione ed infine di scrittura e quindi salvataggio dei risultati. Le operazioni di I/O sappiamo essere delle operazioni molto più lente in quanto abbiamo che la velocità di funzionamento di un disco risulta essere molto più lenta rispetto a quella della memoria centrale. Supponiamo di profilare un programma e quindi mandarlo in esecuzione ed annotare tutti i tempi di esecuzione del programma. Nel nostro caso abbiamo che se andassimo ad eseguire questo programma in un sistema monoprogrammato abbiamo che il tempo effettivo di utilizzo della CPU sarà del solo 3.2%. Storicamente il miglioramento per utilizzo della CPU avvenne con l'introduzione dei sistemi a lotti la cui successiva evoluzione fu quella dei sistemi multi programmati nei quali ci si orientò verso dei sistemi in cui potevano essere eseguiti più programmi.

Nei sistemi multi programmati il SO era costituito da un loader al quale era affiancato un sequenziatore che aveva la funzione di mettere in sequenza i diversi processi da eseguire, era infine presente un gestore degli output. La rappresentazione di un sistema mono programmato risulta essere molto semplice in quanto un programma nella sua esecuzione avrà tempi di elaborazione della CPU e tempi di elaborazione di I/O, cioè quei tempi in cui la CPU non viene ad essere utilizzata. Si susseguono quindi sull'asse temporale tempi di RUN a tempi di WAIT, quindi tempi in cui la CPU lavora a tempi in cui la CPU sta in attesa.

Se in memoria andiamo a caricare più programmi che nei sistemi Batch prendono il nome di JOB abbiamo che in memoria ci sarà una parte in cui abbiamo il SO e tutta la parte di management del JOB ed un'altra parte dove invece andiamo a caricare i diversi JOB. Un'architettura di questo tipo, multi programmata, per essere realizzata ha necessità di avere oltre ad un micro controllore anche un interrupt che permette di rendere asincrona l'attività del processore rispetto a quella di I/O; l'interrupt permette di poter richiedere la CPU per un'attività di I/O e permette di avvisare il sistema quando tale attività è terminata. Anche l'accesso in memoria verrà a non essere controllato dalla CPU ma da un altro elemento che prende il nome di DMA. In un sistema multi programmato nel caso in cui il sistema deve eseguire due programmi abbiamo che viene ad essere eseguito per primo il Programma A poi quando viene ad essere rilevata un'operazione di I/O abbiamo che la CPU si mette in WAIT a questo punto interviene il Process Job Management che assegna la CPU al Programma B che va in RUN. Seguendo questa alternanza di fasi abbiamo che i Programmi A e B vengono ad essere eseguiti. Se andiamo a calcolare la percentuale di utilizzo della CPU abbiamo che in questo caso tale percentuale risulta essere raddoppiata, quindi più programmi abbiamo e più alta sarà la percentuale di utilizzo della CPU, questo risulta essere il punto essenziale dei sistemi multi programmati.

Consideriamo un esempio nel quale supponiamo di avere 3 JOB.

• JOB 1 -> Heavy Compute o CPU Bound rappresenta un processo che utilizza molto la CPU. Tale processo ha una durata di esecuzione di 5 min, richiede per l'esecuzione una memoria di 50Mb e non richiede l'utilizzo di altre risorse.
• JOB 2 -> Heavy I/O o I/O Bound sono dei processi che hanno molte operazioni di I/O. Tale processo ha una durata di 15min, richiede per l'esecuzione 100Mb di memoria e richiede l'utilizzo di un altro terminale.
• JOB 3 -> Heavy I/O o I/O Bound sono dei processi che hanno molte operazioni di I/O. Tale processo ha una durata di 10min, richiede per l'esecuzione 75Mb di memoria e richiede l'utilizzo di due terminali un disco e una stampante.

L'obiettivo è quello di andare a quantificare i vantaggi di eseguire questi 3 JOB in un sistema multiprogrammato.

In un sistema mono programmato abbiamo che l'esecuzione dei JOB è tutta sequenziata e quindi verrà eseguito prima il JOB 1, poi il 2 ed infine il 3. In un sistema mono programmato il tempo di esecuzione è dato dalla somma dei tempi di esecuzione dei vari JOB. Se andassimo ad eseguire questo programma in un sistema multi programmato avremmo che tutti i JOB cominciano nello stesso momento, in questo caso CPU e MEMORIA verrebbero ad essere utilizzate di più e questo perché si avrebbe una sovrapposizione completa dei JOB (overlap), le percentuali di utilizzo delle risorse risulterebbero quindi essere maggiori.

Se andiamo a quantificare nell'esempio fatto quelli che risultano essere i vantaggi di un sistema multiprogrammato rispetto ad uno monoprogrammato avremmo che raddoppiano quasi tutte le percentuali di utilizzo e si ha una diminuzione del tempo di esecuzione totale. Un valore molto interessante da osservare è il Throughput che rappresenta il numero di processi che vengono ad essere eseguiti in un'ora. Throughput e Response Time sono due grandezze correlate ed inversamente proporzionali.

Se aumenta molto il Throughput e quindi la percentuale di utilizzo delle risorse gli utenti cominciano ad essere scontenti, per avere un alto livello di multiprogrammazione sono stati introdotti i sistemi a condivisione di tempo (Time Sharing). Nei sistemi Time Sharing la CPU la si va a dividere tra diversi programmi e quindi per l'esecuzione di più programmi non si attende la fine di uno per cominciare ad eseguire l'altro. La CPU nei sistemi Time Sharing viene ad essere divisa in tempi di esecuzione e questo consente di assegnare un tempo di esecuzione ad ogni processo e di portare avanti l'esecuzione di più processi in concomitanza e questo consente di avere la percezione di tempi di risposta più rapidi. Il Time Sharing è possibile grazie ad un meccanismo che prende il nome di context switch che permette di poter switchare appunto da un processo in esecuzione ad un altro.

Consideriamo di avere due programmi, in un sistema Time Sharing quando viene fatto il RUN di un programma abbiamo che tale sistema comincia ad eseguire il programma, ad un certo punto interviene un timer che scaduto l'intervallo di tempo di esecuzione assegnato al primo programma passa l'utilizzo della CPU al secondo e così via per il resto dell'esecuzione. Questo Timer altro non è che un'interruzione software che va a richiamare la ISR all'interno del SO che salva lo stato del processo che si va interrompere e attraverso lo scheduler assegna il controllo della CPU ad un altro programma. Nel caso in esempio essendoci solo due programmi abbiamo che quando scade il tempo assegnato al secondo processo nuovamente interviene l'ISR che salva lo stato di esecuzione del secondo processo, interpella lo scheduler e passa nuovamente il controllo al processo 1 che era stato precedentemente interrotto, prima di passare però il controllo della CPU al primo processo viene ad essere ricaricato quello che era lo stato dell'esecuzione del processo prima che venisse ad essere interrotto.

Il tempo della CPU risulta essere condiviso tra i processi in esecuzione e quindi riusciamo a portare avanti più processi e per quanto riguarda i tempi di risposta abbiamo che minore risulta essere il tempo T (Time Slice) minore sarà il tempo di risposta. Lo svantaggio di questa tipologia di sistemi rispetto ai sistemi di tipo Batch è che devono essere salvate le informazioni prima di passare il controllo della CPU ad un altro processo e poi tali informazioni devono essere ricaricate quando il controllo ripassa al processo interrotto, questo prende il nome di overhead del SO (sovraccarico) e cresce al decrescere di T. In un sistema Batch i JOB vengono ad essere sequenziati ed eseguiti uno alla volta mentre in un sistema di tipo Time Sharing si cerca di privilegiare il tempo di risposta e quindi il tempo della CPU viene ad essere diviso tra più processi e questo permette di portare avanti più processi alla volta. I sistemi Batch multi programmati massimizzano l'uso del processore e quindi massimizzano il Throughput, i sistemi Time Sharing minimizzano quello che è il tempo di risposta. Gli obiettivi dei due sistemi sono diversi infatti per il primo abbiamo che è orientato al sistema mentre per il secondo all'utente. Questi sistemi sono controllati rispettivamente attraverso un system control language mentre il secondo attraverso un controllo con interprete dei comandi.

I sistemi di oggi sono dei sistemi multi programmati. I sistemi di Mobile Computing non hanno l'obiettivo di massimizzare l'utilizzo del processore o l'utilizzo della memoria ma sono orientati all'utente ed ai tempi di risposta. Tale tipologia di sistemi Mobile Computing sono una tipologia di sistemi in cui il multitasking non è gestito da uno scheduler ma dall'utente stesso che selezionando l'applicativo da utilizzare decide a quale applicativo dedicare le risorse del terminale.

Tale tipologia di sistemi sono orientati poi alla sicurezza e alla privacy ma anche a problemi di efficienza energetica e quindi sono orientati ad esempio alla gestione del processore onde evitare che lavori quando non necessario, consumando energia. Tale tipologia di sistemi sono orientati al multimediale e quindi sono per lo più equipaggiati con delle GPU che sono molto forti sulle operazioni su interi piuttosto che ad esempio su operazioni su flatting point, questo spiega perché ad esempio ARM e CORTEX stanno prendendo piede, appunto perché sono molto forti sulla parte multimediale.

Il paradigma del cloud computing è stato reso possibile grazie alle tecnologie di virtualizzazione e a quelle che si chiamano Hyper Visor che sono molto simili ai SO ma hanno obiettivi diversi rispetto ai SO stessi. Il Cloud Computing oggi è molto utilizzato a livello aziendale dove si preferisce affittare un'infrastruttura informatica che è hostata e condivisa in base alla tariffa che si preferisce a seconda di quelle che sono le esigenze computazionali richieste.

Lezione 2

Un SO evolve attraverso meccanismi asincroni e non è da pensarsi strutturato come un normale programma con un int main. Un SO come abbiamo detto nella lezione precedente si pone nel mezzo tra l'hardware e i processi ed ha un duplice ruolo: da un lato gestisce le risorse hardware e quindi garantisce l'accesso sicuro ai processi verso queste risorse; per sicuro si intende che due processi non potranno accedere contemporaneamente ad una stessa memoria o ad uno stesso buffer, vengono quindi implementati dei meccanismi di protezione ma anche per permettere la cooperazione di processi. Un SO permette quindi la cooperazione dei processi e gestisce le risorse. Il ruolo fondamentale di un SO è la gestione ed il coordinamento delle risorse dove per gestione si intende implementare meccanismi di protezione del sistema hardware, la cooperazione dei processi è invece una sorta di astrazione delle risorse per essere controllate al meglio. Un SO virtualizza le risorse hardware, per virtualizzazione si intende ad esempio far credere al processo di avere a disposizione una CPU ed una memoria dedicata. Quando scriviamo un programma non ci preoccupiamo della CPU o della I/O. Chi si assicura che la CPU venga data al programma 1 o al 2 è il SO che si occupa di dare una virtualizzazione della CPU. Nei sistemi Time Sharing abbiamo visto come funziona il SO che interrompe il processo 1 e attraverso lo scheduler dà il controllo al processo 2 e viceversa. Il SO fa sì che il livello kernel virtualizzi la CPU, attraverso il timer e la funzione scheduler fa sì che i programmi a questo livello vedano come se ci fosse una sola CPU.