Sistemi operativi
Qualche definizione di Sistema Operativo (S.O.) - è un interfaccia tra uomo e computer
- è un allocatore di risorse (hw e sw) che possono servire per risolvere un problema: tempo di CPU, spazio di memoria, spazio disco, device di I/O…
- fornisce un ambiente nel quale altri programmi possono essere eseguiti in modo proficuo.
- è un programma di controllo, che controlla l’esecuzione dei programmi utente per prevenire errori ed uso improprio del computer.
- ...
I S.O. esistono perchè si suppone sia più conveniente usare un computer che ha un S.O. piuttosto che uno che non ce l’ha e perchè si suppone rendano più efficiente l’esecuzione dei programmi da parte del computer.
Questi due obiettivi, in passato, potevano essere in conflitto.
Breve storia dei S.O.
Con i primi computer il programmatore faceva anche l’operatore; scriveva i programmi, li caricava maualmente (panel switch, schede perforate, nastro perforato), definiva l’indirizzo di partenza del programma, pigiava start e durante l’esecuzione osservava le luci di controllo. Se il programma andava in errore, esaminava il contenuto della memoria e dei registri. Alla fine l’output veniva stampato.
Man mano che l’hardware diventò più complesso vennero create delle librerie di routine per i compiti più comuni. Fu molto importante la creazione delle routine di I/O (device driver), perchè, senza di esse, il programmatore avrebbe dovuto conoscere le caratteristiche di ciascun device per poterlo utilizare nel proprio programma. Un device driver sa come devono essere usati i buffer, i flag, i registri, i bit di controllo e di stato per un device.
L’apparire dei compilatori per i linguaggi FORTRAN e COBOL rese più facile il lavoro dei programmatori, ma più complesse le operazioni per eseguire un programma.
Infatti doveva essere montato un nastro con il compilatore, il compilatore produceva un output in assembly che doveva essere assemblato, perciò doveva essere montato il nastro con l’assemblatore, l’output doveva essere linkato con le librerie… Se si verificava un errore in qualche punto tutto doveva ricominciare dall’inizio.
Si dice job l’insieme delle azioni di compilazione, linking ed esecuzione.
Il tempo di set-up del job rappresentava un problema perchè, ad esempio, mentre un nastro veniva montato, la CPU era in idle, cioè non stava facendo nulla.
Venne perciò introdotta la figura dell’operatore ed i programmatori non operarono più sul computer. Il tempo di set-up venne ridotto a causa della maggiore esperienza dell’operatore. Ovviamente egli non poteva debuggare, perciò veniva fornito al programmatore un dump, ma il lavoro di debug diventò così più difficile. D’altra parte l’operatore poteva ottimizzare il set-up dei job sequenzializzandoli in modo opportuno.
In questo modo migliorò l’uso della CPU, tuttavia rimanevano momenti nei quali essa era in idle, ad esempio, ogni volta che un job terminava, l’operatore doveva verificare se la terminazione era stata normale o anormale, eventualmente fare il dump, caricare il job successivo nell’appropriato device e restartare il computer.
Per eliminare questi tempi morti nell’uso della CPU venne inventata la sequenzializzazione automatica dei job, che costituì il primo rudimentale S.O. Fu scritto un piccolo programma chiamato monitor residente (in memoria), in grado di trasferire automaticamente il controllo da un job al successivo. Il computer però, come prima l’operatore, doveva essere informato dei passi attraverso i quali il job doveva evolvere. Ciò venne fatto con schede di controllo aggiunte ai programmi ed ai dati, esse contenevano delle direttive al monitor. I S.O. con queste caratteristiche sono detti batch.
Con essi è andata perduta l’interazione tra il programmatore ed il computer. Tuttavia esistevano ancora momenti nei quali la CPU si trovava in idle, dovuti alla lentezza dei dispositivi meccanici rispetto a quelli elettronici.
L’offline processing permise di parallelizzare le operazioni di I/O. In questa situazione la CPU non leggeva direttamente dal lettore di schede nè stampava direttamente sulla stampante, invece le schede venivano copiate su nastro per mezzo di un device separato. Quando il nastro era sufficientemente pieno veniva preso e portato sul computer.
Quando un programma richiedeva in input una scheda, il record equivalente veniva letto dal nastro. Allo stesso modo, l’output veniva scritto su nastro e stampato più tardi. I lettori di schede e le stampanti lavoravano quindi off-line rispetto al computer principale. Il vantaggio reale di questa tecnica stava nella possibilità di usare più sistemi card reader-to-tape
CPU
card reader
card reader
line printer
CPU
tape unit tape unit line printer
e tape-to-printer per una CPU. Sui nastri però, essendo supporti ad accesso sequenziale, non si può leggere da una parte e scrivere su di un’altra.
La diffusione dei dischi introdusse lo spooling (simultaneus peripheral operation on-line). Gli input venivano caricati su disco e la CPU leggeva le schede del job da disco. Se veniva richiesto di stampare una linea, essa veniva stampata su disco e solo alla fine del job veniva effettivamente stampata sulla stampante.Con la tecnica dello spooling il disco viene usato come un buffer molto grande per leggere, appena è possibile, dai device di input e scrivere file di output finchè i device di output non sono in grado di effettuare l’operazione richiesta. Lo spooling permette di sovrapporre l’I/O di un job con la computazione di un altro.
Con lo spooling venne introdotto il job pool, che è alla base dei sistemi batch multiprogrammati. In effetti, con lo spooling, accade che su disco risiedano più job che sono già stati letti e che sono in attesa, pronti ad essere eseguiti.
Diventò così possibili effettuare un job scheduling, cosa che con i nastri (ad accesso sequenziale) non era possibile fare.
L’idea era quella di mantenere in memoria centrale un sottoinsieme del job pool. Quando un job è sospeso perchè aspetta qualche evento (ad esempio che sia montato un nastro) ne viene schedulato un altro. Con la multiprogrammazione, per la prima volta, era il sistema a prendere decisioni. Il programmatore non poteva interagire con il computer durante l’avanzamento del proprio job, perciò le schede di controllo dovevano tener conto di tutte le possibili situazioni, cosa non sempre facile, ed il debug era statico.
Il time sharing (multitasking) è una estensione logica della multiprogrammazione. Con il time sharing l’uso della CPU è ripartito in brevi intervalli ed il programmatore può interagire con il sistema attraverso tastiera e video. Non ci sono più schede di controllo, il S.O. cerca cosa deve fare aspettando gli input da tastiera. In questo modo è stato possibile riottenere l’interattività, già esistenete nei sistemi più primitivi, senza però avere momenti di inattività della CPU.
Nei S.O. interattivi ogni utente ha almeno un programma caricato in memoria. Un programma residente in memoria ed in esecuzione è chiamato processo. Poichè il computer passa rapidamente da un processo all’altro, ogni utente ha l’impressione di avere un sistema tutto per sè.
L’idea del time sharing è del 1960, ma fu implementata a partire dagli anni 70. Da allora tutti i sistemi hanno sia funzionalità batch che time sharing, anche se una delle due può prevalere sull’altra. I sistemi batch son adatti per eseguire grandi job che necessitano di scarsa interazione, l’utente una volta fatta iniziare l’esecuzione, se ne può andare e tornare più tardi per vedere i risultati. I job interattivi tendono ad essere formati da molte azioni brevi, l’utente dà un comando e attende l’esito per decidere quale sarà il passo successivo.
I S.O. time sharing sono piuttosto complessi, infatti, dovendo gestire l’avanzamento contemporaneo di più processi e l’accesso al sistema, in modo interattivo, da parte di più utenti devono:
1. decidere la politica di scheduling della CPU
2. gestire l’allocazione dei processi in memoria centrale, garantendo meccanismi di protezione nell’accesso alla memoria da parte dei processi
3. gestire i dischi ed i file, garantendo meccanismi di protezione nell’accesso ai file da parte di diversi utenti 4. …….
Con il decrescere del costo dell’hardware è stato di nuovo possibile avere di nuovo un computer dedicato ad un solo utente, ma, a differenza dei sistemi primitivi, l’uso della CPU non è più un obiettivo primario. I S.O. per questi computer sono perciò molto elementari in quanto non devono tener conto delle problematiche che esistono con la multiprogrammazione ed il time sharing, problematiche che, non deve essere dimenticato, sono state introdotte dalla necessità di evitare tempi di idle della CPU.
Schema base di un computer
Un generico computer è composto da una CPU e da un certo numero di device controller .Essi sono collegati atrraverso un bus comune che fornisce l’accesso alla memoria condivisa (shared memory) . Ogni device controller ha in carico la gestione di uno specifico device (disk drive, device audio e video), in qualche caso ci può essere più di un device collegato ad un solo controller (SCSI Small Computer System Interface). La CPU e i device controller possono eseguire azioni parallelamente, in competizione per l’uso della memoria. Per garantire un corretto accesso alla memoria esiste anche per essa un controller che ha il compito si sincronizzarne gli accessi.
Quando un computer viene acceso ha bisogno di un programma iniziale da eseguire. Questo programma (bootstrap program) è semplice; inizializza tutto il sistema, i registri della CPU, i controller e la memoria. Deve anche sapere come caricare il S.O. e come iniziare ad eseguirlo. Il programma di bootstrap carica in memoria il kernel del S.O., mette in esecuzione il primo processo, che di solito si chiama init, e aspetta che accada qualche evento. Di solito il verificarsi di un evento è segnalato da un interrupt hardware o software( gli interrupt software sono anche detti trap o eccezioni).
L’hardware invia un interrupt alla CPU attraverso il bus di sistema, il software invia un interrupt eseguendo particolari operazioni chiamate system call. Ci sono molti e diversi tipi di eventi che causano un interrupt: il completamento di una operazione di I/O, divisioni per zero, accessi non corretti alla memoria, una richiesta di un servizio al S.O...
I S.O. moderni sono interrupt driven, se non ci sono processi da eseguire, nè device di I/O da servire, nè utenti ai quali rispondere, allora un S.O. sta tranquillo, aspettando che qualcosa accada.
Modalità di esecuzione delle istruzioni
Il desiderio di migliorare l’utilizzo del computer ha portato allo sviluppo della multiprogrammazione e del time sharing, dove le risorse sono ripartite tra più processi. L’uso ripartito delle risorse ha portato all’introduzione di modifiche nell’architettura base di un computer, per permettere al S.O. di mantenere il controllo del sistema e soprattutto dell’I/O.
A tal fine sono state introdotte due modalità di esecuzione delle istruzioni: user mode e kernel (monitor) mode. Le istruzioni per accedere alle risorse condivise sono privilegiate e possono essere eseguite solo in kernel mode. Anche l’istruzione per passare da user mode a kernel mode è privilegiata. Le istruzioni di I/O sono privilegiate, quindi devono essere eseguite in kernel mode. Come può quindi un programma utente eseguire una operazione di I/O? Il programma utente deve chiedere al kernel di eseguire una operazione di I/O per conto del programma utente stesso.
Tale richiesta è detta system call. Una system call, di solito, si realizza attraverso un trap (interrupt software) ad una specifica locazione nel vettore delle interruzioni. Quando il controllo passa alla routine di servizio, allora avviene anche la transizione da user mode a kernel mode. Quando la routine termina il controllo torna al programma utente.
Gestione dei processi
Un programma di per sè non è un processo, è un’entità passiva, è il contenuto di un file memorizzato su disco. Un processo, invece, è un’entità attiva, con un program counter che specifica la prossima istruzione da eseguire. Un processo è un unità di lavoro in un sistema. Tale sistema è formato da un insieme di processi, alcuni dei quali sono processi del sistema operativo (quelli che eseguono codice di sistema) e altri sono processi utente (quelli che eseguono codice utente). Tutti questi processi possono potenzialmente essere eseguiti concorrentemente, multiplexando la CPU tra di loro.
I S.O. è responsabile delle seguenti attività riguardo la gestione dei processi:
creare e terminare i processi utente e di sistema
sospendere e riprendere l’esecuzione dei processi
fornire meccanismi di sincronizzazione
fornire meccanismi di comunicazione
fornire meccanismi di trattamento del deadlock.
