Sistemi Operativi ingegneria informatica PDF

Preview

Summary

Un ottimo riassunto per preparare la materia in vista dell'orale...

Description

STATI DI UN PROCESSO Un processo viene definito come un’entità dinamica il cui stato varia nel tempo, formalmente è un programma in esecuzione, comprensivo del valore corrente del program counter, dei registi e delle variabili: Il codice del programma è normalmente contenuto in un file memorizzato su disco; al momento dell’attivazione il codice viene caricato dal sistema operativo nella memoria del computer, da dove pu essere effettivamente eseguito, da questo momento il programma diviene un processo. Dal punto di vista del sistema operativo un processo è la più piccola entità che possa individualmente richiedere l'uso della CPU per l'esecuzione, e sempre per il sistema per il sistema operativo, l'evolvere di un processo durante la sua esecuzione non è altro che il passaggio attraverso una successione di Stati. Nel corso della propria esecuzione normalmente un processo impiega, oltre al processore, altre risorse hardware o software rese disponibili dal sistema operativo: memoria allocata, file aperti, connessioni di rete attivate, dispositivi di input e di output utilizzati, ecc. Il sistema operativo contiene tutte le informazioni necessarie per gestire un particolare processo in una struttura dati chiamata descrittore di processo il quale contiene tutti gli attributi del processo sia statici che dinamici: nome del processo, stato del processo(pronto, in esecuzione sospeso), priorità, utilizzo delle risorse, identificazione del processo successivo, contesto del processo. Le informazioni contenute nei descrittori sono essenziali per il SO e devono essere opportunamente protette, difatti essi vengono memorizzati in a’area di memoria accessibile solo dal nucleo del SO. Nella nella forma più generale, un processo puo’ assumere due stati: attivo o bloccato, a sua volta lo Stato attivo viene suddiviso in due stati: pronto e in esecuzione. Dunque in definitiva avremo 3 stati: 1) in esecuzione o running (il processo sta effettivamente utilizzando la CPU) 2) pronto o ready (il processo è eseguibile ma temporaneamente sospeso per consentire l’esecuzione di un altro processo) 3) bloccato (il processo è impossibilitato a eseguire fino al verificarsi di un evento esterno) ll passaggio dallo stato di pronto a quello in esecuzione comporta una scelta tra tutti i processi pronti, questa scelta viene compiuta da una funzione di gestione del processore detta scheduling facente parte del sistema operativo il cui compito è prooprio quello di assicurare che i processi pronti possano avanzare. In particolare, un processo pronto possiede tutte le risorse necessarie alla sua esecuzione tranne la CPU. Dopo essere stati creati, i processi si trovano solitamente nello stato pronto in attesa che il sistema operativo assegni loro la CPU per poter passare in esecuzione. I processi pronti sono organizzati in una o più code dette code dei processi pronti, ad ogni coda è associato un descrittore di coda che contiene due campi contenenti rispettivamente il primo e l’ultimo indice del descrittore del processo in coda. La CPU ha un registro detto registro del processo in esecuzione contenente il descrittore del processo attualmente in esecuzione. Quando un processo viene revocato o comunque torna allo stato di pronto da esecuzione o bloccato, viene inserito nella coda, mentre quando un processo pronto viene eseguito viene prelevato dalla testa della coda e inserito nel registro del processo in esecuzione. Il dispositivo che si occupa di implementare le politiche di gestione dei processi è lo scheduler, che vedremo essere di tre tipi; mentre il dispatcher è il componente che si occupa di applicare le strategie e quindi effettuare il cambio di contesto. Un processo in esecuzione possiede tutte le risorse necessarie per la sua esecuzione compresa la CPU mentre un processo sospeso è in attesa che gli vengono assegnate alcune risorse oltre alla CPU, quali, per esempio, dei segnali di sincronizzazione; questi processi non competono per le esecuzioni fintanto che non vengono rimosse le condizioni che ne hanno provocato la sospensione. Si precisa che un processo in esecuzione pu

venire sospeso all'atto della chiamata di una routine di I/O. In tal caso, il Sistema operativo tiene traccia dei motivi delle sospensioni in modo da poter successivamente riattivare il processo quando le condizioni che lo hanno sospeso vengono rimosse da altri processi o dell'arrivo di eventi esterni. È importante notare come un processo interrotto rimanga in stato di pronto e non in stato di sospeso perché l'unica risorsa che gli manca è il processore . Per quanto riguarda lo stato bloccato risulta ridondante specificare che esso non sarà eseguito anche se ci fosse una CPU libera. Per completezza occorre pero’ aggiungere due ulteriori stati: nuovo e terminato; possiamo, quindi, delineare in un sistema multiprogrammato un modello a 5 stadi: •new(nuovo), il processo viene creato •running(in esecuzione), le istruzioni vengono eseguite •waiting (in attesa), il processo è in attesa di un evento •ready(pronto), il processo è in attesa di essere assegnato ad un processore •terminated(terminato), il processo ha terminato la propria esecuzione. Nello stato di Run vi possono essere al massimo tanti processi quanti sono i processori, in particolare, su computer con un solo processore solo un processo pu trovarsi in stato di Run, ma negli stati di Wait e di Ready vi possono essere numerosi processi in attesa di essere sbloccati o selezionati dal sistema operativo. Il diagramma qui di seguito rappresenta le transizioni da uno stato all’altro:

Esiste infine anche lo stato swapped in cui un processo viene spostato temporaneamente in una memoria di massa per far posto ad altri processi, altresi’ ci sono processi la cui esecuzione è terminata ma che sono in attesa di essere eliminati in maniera definitiva dal processo padre. Questo stato è denominato Zombie. Dunque, concludendo un processo transita dallo stato di esecuzione allo stato terminato e poiché, in linea generale, il numero di CPU è minore del numero dei processi, alcuni processi saranno in esecuzione, altri saranno bloccati altri ancora pronti per essere eseguiti. Esiste quindi una coda dei processi pronti da mandare in esecuzione e una coda per i processi bloccati. Tra i processi pronti ne esiste uno chiamato processo fittizio (dummy process) che va in esecuzione quando tutti i processi sono temporaneamente bloccati. Esso ha la proprietà più bassa, è sempre nello stato di pronto e rimane in esecuzione fino a quando qualche altro processo diventa pronto con lo scopo di mantenere impegnata la CPU. Sarà poi la politica di gestione dello scheduling che avrà l’onere di dover scegliere quale processo mettere in esecuzione tra quelli pronti sulla base di criteri prefissati. Per quanto concerne il passaggio di un processo in esecuzione ad un

altro scelto dalla coda dei processi pronti prende il nome di cambio di contesto comportando un overhead relativo all’utilizzo della CPU.

IN UN SISTEMA A TIME-SHARING DESCRIVERE GLI STATI DEI PROCESSI IN UN SISTEMA MULTI-PROGRAMMATO Prima di addentrarci nel particolare di un sistema a time-sharing multiprogrammato si rende necessario definire il concetto di processo e degli stati che esso assume: un processo viene definito come un’entità dinamica il cui stato varia nel tempo, formalmente è un programma in esecuzione, comprensivo del valore corrente del program counter, dei registi e delle variabili. Dal punto di vista del sistema operativo un processo è la più piccola entità che possa individualmente richiedere l'uso della CPU per l'esecuzione, e sempre per il sistema per il sistema operativo, l'evolvere di un processo durante la sua esecuzione non è altro che il passaggio attraverso una successione di Stati. Nella nella forma più generale, un processo puo’ assumere due stati: attivo o bloccato, a sua volta lo Stato attivo viene suddiviso in due stati: pronto e in esecuzione. Dunque in definitiva avremo 3 stati: 1) in esecuzione o running (il processo sta effettivamente utilizzando la CPU) 2) pronto o ready (il processo è eseguibile ma temporaneamente sospeso per consentire l’esecuzione di un altro processo) 3) bloccato (il processo è impossibilitato a eseguire fino al verificarsi di un evento esterno) ll passaggio dallo stato di pronto a quello in esecuzione comporta una scelta tra tutti i processi pronti, questa scelta viene compiuta da una funzione di gestione del processore detta scheduling facente parte del sistema operativo il cui compito è proprio quello di assicurare che i processi pronti possano avanzare. In particolare, un processo pronto possiede tutte le risorse necessarie alla sua esecuzione tranne la CPU. Dopo essere stati creati, i processi si trovano solitamente nello stato pronto in attesa che il sistema operativo assegni loro la CPU per poter passare in esecuzione. Un processo in esecuzione possiede tutte le risorse necessarie per la sua esecuzione compresa la CPU mentre un processo sospeso è in attesa che gli vengono assegnate alcune risorse oltre alla CPU, quali, per esempio, dei segnali di sincronizzazione; questi processi non competono per le esecuzioni fintanto che non vengono rimosse le condizioni che ne hanno provocato la sospensione. Per quanto riguarda lo stato bloccato risulta ridondante specificare che esso non sarà eseguito anche se ci fosse una CPU libera. Per completezza occorre pero’ aggiungere due ulteriori stati: nuovo e terminato; possiamo, quindi, delineare in un sistema multiprogrammato un modello a 5 stadi: •new(nuovo), il processo viene creato •running(in esecuzione), le istruzioni vengono eseguite •waiting (in attesa), il processo è in attesa di un evento •ready(pronto), il processo è in attesa di essere assegnato ad un processore •terminated(terminato), il processo ha terminato la propria esecuzione. Dunque, riassumendo un processo transita dallo stato di esecuzione allo stato terminato e poiché, in linea generale, il numero di CPU è minore del numero dei processi, alcuni processi saranno in esecuzione, altri saranno bloccati altri ancora pronti per essere eseguiti.

Tornando ora ad un sistema a time-sharing (condivisione di tempo) multiprogrammato, esso di definisce tale poiché in un certo istante saranno presenti nella RAM, i codici, i programmi corrispondenti a piu’ processi di cui uno solo è in esecuzione. La politica di gestione della CPU del time-sharing prevede, dunque, di assegnare la CPU a turno ai vari programmi utente per un limitato periodo di tempo chiamato time-slice o quanto. Si realizza un sorta di parallelismo apparente, virtuale: tutti i programmi vengono fatti evolvere “ contemporaneamente” anche se in realtà in ogni istante uno solo di essi è in esecuzione con la CPU. In pratica il sistema operativo seleziona e inizia ad eseguire uno dei programmi in memoria. In un certo istante, il programma in esecuzione potrebbe eseguire un’operazione di I/O e trovarsi in attesa del suo completamento. In tale situazione, in un sistema NON multiprogrammato, la CPU sarebbe inattiva mentre in un sistema MULTIPROGRAMMATO il Sistema Operativo passa semplicemente ad eseguire un altro programma. Quando i programmi terminano l’attesa, possono essere di nuovo selezionati dal SO per tornare nuovamente in esecuzione. Il time-sharing è in buona sostanza l’estensione del concetto di multiprogrammazione: il tempo di esecuzione della CPU viene suddiviso in intervalli (quanti) dell’ordine di alcune decine di millesecondi. Allo scadere di un quanto l’esecuzione del processo corrente viene interrotta, anche se non deve fare operazioni di I/O, e si passa ad un altro processo. Il contest-switch (il passaggio ) è molto rapido e trasparente all’utente che avrà quindi l’impressione che vengano eseguiti molti programmi in parallelo. Quindi da una parte abbiamo la multiprogrammazione con la quale è possibile aumentare nettamente l’efficienza d’uso della CPU, rispetto ai sistemi monoprogrammati, fino a raggiungere valori superiori dell’80%, dall’altra abbiamo la tecnica del time-sharing il cui obiettivo principale è minimizzare il tempo di risposta dei programmi e quindi minimizzare il tempo di attesa medio da parte degli utenti per ottenere dal programma una risposta alle richieste effettuate. L’operazione di scheduling della CPU avrà, poi, l’onere di dover scegliere quale processo mettere in esecuzione tra quelli pronti sulla base di criteri prefissati. Alla luce delle considerazioni fatte bisogna considerare, anche, il tempo necessario per commutare la CPU da un programma ad un altro. Tale meccanismo detto cambio di contesto porta ad un aumento dell’overhead (percentuale di tempo in cui la CPU è utilizzata da parte del sistema operativo rispetto al tempo totale) di sistema. Infatti quando la CPU è assegnata ad un altro programma il SO deve eseguire varie operazioni tra cui il salvataggio dello stato della CPU (il valore di tutti i suoi registri) e analogamente nel momento in cui riprenderà l’esecuzione del programma precedentemente interrotto, la Cpu dovrà ripristinare i propri registri andando a recuperare dalla memoria i valori ad essi relativi. Per tanto, avremo un’aumento dell’ overhead relativo all’utilizzo della CPU a causa di quello che viene propriamente detto cambio di contesto. Infine, ricordiamonche in queste tipologie di sistemi viene, altresi’, implemento il cosiddetto sistema di swapping: quando la memoria centrale non ha dimensioni tali da contenere tutti i programmi da eseguire concorrentemente effettua un trasferimento ( swapping) del contenuto da un’area della memoria centrale in un’altra della memoria di massa (area di swap).

CAMBIO DI CONTESTO Il cambio di contesto (context switch) descrive le operazioni necessarie per passare dall'esecuzione di un processo ad un altro, in altri termine, è quella parte del kernel del sistema operativo che cambia il processo correntemente in esecuzione su una delle CPU. Questo permette a più processi di condividere una stessa CPU, ed è utile quindi sia nei sistemi con un solo processore, perché consente di eseguire più programmi contemporaneamente, sia nell'ambito del calcolo parallelo, perché consente un migliore bilanciamento del carico. Si consideri la situazione di due processi P1 e P2 che si alternano nell’esecuzione in un sistema che opera in multiprogrammazione. Inizialmente il processo P1 è running. All’istante t1 scade il time slice di P1 e l’orologio di sistema invia un’interrupt. La gestione dell’interruzione causa l’intervento del sistema operativo che, scegliendo tra i processi nello stato ready, decide di mandare in esecuzione il processo P2. Il passaggio dall’esecuzione di P1 all’esecuzione di P2 definisce quindi il cambiamento di contesto. Affinchè il contest switch venga svolto correttamente bisognerà prima di tutto salvare lo stato della computazione del processo correntemente in esecuzione, tra cui il program counter ed il contenuto dei registri generali, in modo che l'esecuzione potrà essere ripresa in seguito. Queste informazioni sullo stato del processo vengono generalmente salvante nel PCB (Process Control Block-descrittore del processo) del processo. Successivamente lo scheduler sceglierà un processo dalla coda pronti, in base alla propria politica di scheduling, e accederà al suo PCB per ripristinare il suo stato nel processore, in maniera inversa rispetto alla fase precedente. Quindi, le operazioni svolte nel cambio di contesto possono essere sintetizzate quanto segue: 1) salvataggio del contesto del processo in esecuzione nel suo descrittore; 2) inserimento del descrittore nella coda dei processi bloccati o dei processi pronti; 3) selezione di un altro processo tra quelli contenuti nella coda dei processi pronti caricamento del nome di tale processo nel registro processo in esecuzione; 4) caricamento del contesto del nuovo processo nei registri del processore; Il tempo dedicato al cambiamento di contesto determina un sovraccarico per il sistema il (overhead), proprio perché in questo intervallo di tempo non ci sono processi utili in esecuzione, ma solo lavoro fatto direttamente dall’hardware o dal sistema operativo per fermare un programma e farne partire un altro. Il valore dell’overhead per cambiamento di contesto, t2- t1 come nell’esempio precedente, varia da sistema a sistema e dipende anche dal supporto hardware disponibile. E’ doveroso sottolineare che si parla comunque di tempi rilevanti, in relazione ai tempi del processore, dell’ordine delle decine o centinaia di microsecondi (msec). Da qui l’importanza e l’interesse verso “processi leggeri” in grado di attuare cambiamenti di contesto in tempi molto più brevi e i thread rispondono proprio a questa esigenza in quanto non possiedono risorse proprie: essi NON HANNO una loro area dove è presente IL CODICE del programma poichè condividono quella del processo che li genera cosG come ne condividono l’area DATI, per tanto, possono essere creati e distrutti piu’ facilmente rispetto ai processi, oltre ad essere piu’ semplici e veloci (condividendo i dati sono meno le informazioni da memorizzare e ripristinare).

TRE POLITICHE DI SCHEDULING Con scheduling si intende un insieme di tecniche, di meccanismi interni del SO che amministrano l'ordine con cui il lavoro viene svolto: quando piu’ processi sono eseguibili il SO deve scegliere quale eseguire per primo e la parte del SO che effettua proprio queste scelte viene chiamata scheduler e l’algoritmo utilizzato viene chiamato algoritmo di scheduling. Uno scheduler è, quindi, un modulo del sistema operativo che seleziona quale “job” debba essere introdotto nel sistema e quale sia il successivo processo ad andare in esecuzione. Il suo obiettivo principale è l'ottimizzazione delle prestazioni secondo certi criteri specificati dai progettisti di sistema. In generale, esistono tre tipi di scheduling: •Scheduling a lungo termine, seleziona quale processo deve essere inserito nella coda dei processi pronti. •Scheduling a breve termine, seleziona quale processo ready deve essere eseguito e alloca la CPU a uno di essi. •Scheduling a medio termine, SWAPPING, trasferisce temporaneamente un processo dalla memoria centrale in memoria di massa (swap-out) o viceversa (swap-in). In particolare, Lo scheduler a lungo termine seleziona i programmi da eseguire dalla memoria secondaria per caricarli in memoria centrale. La scelta viene fatta cercando di equilibrare i processi I/O-bound (operazioni di ingresso e uscita) con quelli CPU-bound (operazioni di elaborazione). Uno sbilanciamento verso uno dei due tipi di programma puo’ rendere poco efficiente e non ottimizzato il sistema. Per tanto, obiettivo dello scheduler a lungo termine sarà quello di controllare il grado di multiprogrammazione ovvero il numero di processi contemporaneamente presenti nel sistema. Insieme allo scheduling a medio termine, dove quest’ultimo ha il compito di liberare parte della memoria centrale per far posto ad altri processi, è un tipo di funzione che viene invocato con frequenza minore e che pu, quindi, permettersi di essere piu’ lento e sofisticato, senza pero’, per questo, inficiare le prestazioni complessive del sistema. Per quanto concerne, lo short term schedule r, gestendo la coda dei processi pronti da mandare in esecuzione, viene, contrariamente agli altri due, invocato molto frequentemente (decine di volte al secondo) e quindi deve essere altamente efficiente e veloce. Lo scheduling a breve termine ci permette di introdurre una prima classificazione fra gli algoritmi di scheduling che prevede di considerare quali siano gli eventi in base al quale lo scheduler debba intervenire: - algoritmi di scheduling senza diritto di revoca (NON preemptive), in questo caso si prevede l’intervento dello scheduler esclusivamente quando il processo in esecuzione libera spontaneamente la CPU - algoritmi di scheduling CON diritto di revoca (preemptive), in questo caso si prevede l’intervento dello scheduler anche per decidere di revocare la CPU al processo in esecuzione al fine di allocarla a un altro fra i processi pronti. Questo puo’ avvenire perhè è scaduto il tempo assegnato a quel processo oppure perché è entrato nella coda dei processi pronti un processo ritenuto piu’ urgente di quello in esecuzione.

Gli scheduling NON preemptive sono sicuramente piu’ semplici perché riducono il numero di intervento dello scheduler ...