01-Sistema Operativo

01-Sistema Operativo.doc.doc - 1 / 5
S4Abacus – Sistemi Operativi
SISTEMI OPERATIVI
DEFINIZIONI
Il concetto di S i s t e m a O p e r a t i v o (O S , O p e r a t i n g S y s t e m , d’ora in avanti S O ) è notevolmente vasto; non è possibile offrire una unica
definizione della sua sostanza funzionale sopratutto perchè si tratta di una classe di applicazioni per calcolatori che ha seguito passo a passo il
veloce sviluppo tecnologico delle materie informatiche ed elettroniche.
E' sicuramente più efficace descrivere e definire il concetto di sistema operativo attraverso le fasi di sviluppo dell'hardware che sottostà a qualsiasi
applicazione informatica. Inoltre questa veloce e repentina trasformazione delle piattaforme hardware è resa più vaga e indeterminabile dalle
pesanti influenze di mercato che hanno determinato sviluppi spesso poco chiari e lineari, ma che hanno frequentemente modificato alcuni assunti
validi solo poco tempo prima.
A tutto ciò si deve aggiungere una situazione tipicamente correlata allo sviluppo commerciale dei prodotti, ambito del quale fanno parte i SO; ogni
azienda produttrice di piattaforme hardware o produttrice di programmi applicativi comunque interessate a distribuire il proprio prodotto ha creato
spesso un sistema operativo proprio, spesso non trasportabile su altre macchine. Tutto ciò per tutelare e garantire la vendita delle proprie
piattaforme hardware o software, ma di fatto impedendo sia la standardizzazione sia la diffusione di modelli operativi condivisibili.
I sistemi operativi nati sotto queste ipotesi progettuali sono detti comunemente s i s t e m i p r o p r i e t a r i e nel tempo hanno rappresentato un serio
problema alla diffusione di standard operativi.
In opposizione ai sistemi operativi proprietari si collocano i s i s t e m i a p e r t i , cioè quei sistemi operativi per cui la casa produttrice distribuisce
documentazione (nel complesso denominata A P I ovvero A p p l i c a t i o n s P r o g r a m I n t e r f a c e ) atta a favorire la scrittura di applicativi sw da
parte di t e r z e p a r t i (la prima parte è il costruttore dell’hardware, la seconda parte è il costruttore del sistema operativo) e, di fatto, base
essenziale per uno sviluppo orizzontale del mercato del sw.
Un’ultima evoluzione di SO, che ne ha condizionato enormemente lo sviluppo, riguarda la schiera dei sistemi operativi o p e n s o u r c e , ovvero
sistemi operativi per cui la distribuzione commerciale è svincolata da costi e il cui codice sorgente è disponibile ai programmatori.
Una prima definizione di SO potrebbe quindi esprimersi:
"un SO è un insieme di programmi sw non accessibili agli utenti per proteggere gli
utilizzatori di un elaboratore dalle complessità di funzionamento dell'hardware".
Esso è lo strato di sw immediatamente superiore all'hw che ne controlla tutte le parti appartenenti al sistema e presenta all'utilizzatore la macchina
come macchina astratta e non più fisica.
Si può usare il seguente diagramma a strati per mostrare le categorie operative di una macchina calcolatrice:
PROGRAMMI UTENTE
SISTEMA OPERATIVO
FIRMWARE
HARDWARE
dove l'hw (hardware) è l'insieme dei dispositivi fisici, il fw (firmware) sono i microprogrammi posti all’interno dell'hw (CPU o Eprom).
La definizione fornita rappresenta il tipico punto di vista espresso dall’utente di un calcolatore, ovvero da colui che usa il software applicativo, cioè i
programmi. In realtà ciò che più conta per l’utente programmatore è un altro aspetto del SO, cioè:
"un SO è un insieme di programmi che offrono al programmatore le risorse
necessarie per scrivere gli applicativi per gli utenti ".
Questa è la definizione che istruisce questo testo, cioè la descrizione dei Sistemi Operativi in funzione delle risorse software (API) che essi
espongono affinchè i programmatori possano scrivere le applicazioni.
Infine esiste un terzo punto di vista che descrive un SO in relazione all’attività di una terza figura operante con i calcolatori, il sistemista:
“un SO è l’insieme di programmi che consentono al calcolatore di rimanere sempre
operativo e aggiornato”.
In questo caso il sistemista usa il SO per configurare, adattare, riparare e aggiornare il sistema affinchè sia in grado di garantire i servizi agli utenti e
ai programmatori.
STORIA
Prima degli anni ’60 non esistevano sistemi operativi per gestire i centri di calcolo dotati di elaboratori elettronici.
Il mercato dell’informatica era in mano a pochi grandi costruttori come I B M e i calcolatori, costosissimi e posseduti solo da grandi aziende o
importanti istituti, erano poco diffus. I programmi venivano scritti off-line, anche su carta, poi tradotti su sopporti meccanici (es. schede perforate) in
S4Abacus – Sistemi Operativi
01-Sistema Operativo.doc.doc - 2 / 5
linguaggio macchina e forniti all’elaboratore per l’esecuzione. I risultati dell’elaborazione comparivano dopo molto tempo. Le fasi operative quindi
erano del tutto separate: I n p u t , caricamento dati e programmi; E s e c u z i o n e , elaborazione dei dati; O u t p u t , produzione dei risultati.
Hardware e software erano quindi del tutto separati, a causa soprattutto della difficoltà delle fasi di I/O (collo di bottiglia dell’I/O, o I / O
B o t t l e n e c k ).
Protagonisti della scena commerciale furono i sistemi IBM, modello IBM 1401 per quanto riguarda l’I/O, e l’elaboratore IBM 7094 come calcolatore.
Le successive rivoluzioni tecnologiche riguardanti l’introduzione dapprima del transistor, quindi dei circuiti integrati al silicio, hanno dato avvio alla
nascita del Sistema Operativo, il cui primo rappresentante significativo prende il nome di I B M O S / 3 6 0 (1964), perché utilizzato sulle innovative
macchine IBM System/360, appartenenti alla categoria dei m a i n f r a m e , ovvero grossi elaboratori che elaborano l’I/O proveniente da numerosi
dispositivi terminali.
Negli anni ’60, accanto ai mainframe vengono distribuiti i m i n i e l a b o r a t o r i , macchine molto meno costose e snelle, per le quali vengono
progettati nuovi sistemi operativi con caratteristiche molto simili a quelli che operano oggi, dapprima M U L T I C S , quindi U N I X (1969), introducendo
il concetto di m u l t i p r o g r a m m a z i o n e con t i m e s h a r i n g : software e hardware divengono integrati per opera del SO, soprattutto per quanto
riguarda la gestione dei dischi (memorie di massa). I processi vengono gestiti dai sistemi operativi per quantità di tempo.
Alla fine degli anni ’70 l’avvento del Personal Computer rivoluziona di nuovo lo scenario, ancora dominato dai sistemi mainframe: sistemi operativi di
piccole dimensioni ma molto efficaci, tutti derivanti da UNIX come Digital C P / M e Microsoft M s D o s consentono di far funzionare macchine
economiche ma ad alte prestazioni, rigorosamente monoprogrammate e monoutente. Sono gli anni delle versioni grafiche dei Sistemi Operativi
(M a c O S e W i n d o w s ), in cui la multiprogrammazione in timesharing viene temporaneamente abbandonata.
Negli anni ’90 lo spunto decisivo proviene dalla tecnologia delle reti (LAN e Internet) che costringe le case produttrici a implementare
multiprogrammazione in timesharing e la multiutenza anche sui Personal Computer, così da contrastare l’enorme mercato del mainframe. Ecco che
vedono la luce e vengono diffusi sistemi operativi client/server di tipo W i n d o w s (Microsoft) e di tipo * N I X (Open Source) che tendono a
contrastare sempre maggiormante il mercato ormai di nicchia dei sistemi operativi per mainframe.
Allo stato attuale (2008) le fasce di Sistemi Operativi più diffusi si possono considerare:
S i s t e m i O p e r a t i v i A p e r t i di tipo Windows, per PC e sistemi di rete
S i s t e m i O p e r a t i v i O p e n S o u r c e di tipo *NIX, per PC, sistemi di rete e mainframe
S i s t e m i O p e r a t i v i P r o p r i e t a r i per sistemi a mainframe.
A questi si devono affiancare tutta una schiera di sistemi operativi s p e c i a l i z z a t i per apparati mobili e sistemi industriali di tipo realtime.
CLASSIFICAZIONI
La realtà dei sistemi operativi moderni (2008) si caratterizza da sistemi che hanno caratteristiche simili e oramai consolidate, quali la multiutenza, la
multiprogrammazione, la gestione del timesharing e della memoria virtuale.
I S O m o n o p r o g r a m m a t i , in grado di mandare in esecuzione un solo processo alla volta su un sistema in cui un solo utente può agire sono
oramai scomparsi, pur avendo rappresentato una rivoluzione sostanziale per l’epoca, come MsDos e MaC OS. L’utilizzo di tali sistemi permane
come simulazione all’interno dei SO moderni (es. modalità 8086 nei sistemi Windows).
Lo stato dell’arte per i SO moderni sono i cosiddetti S O m u l t i p r o g r a m m a t i , multiutente e in time sharing.
Questi sistemi possono gestire piu’ processi contemporaneamente, per i quali alternano un preciso quanto di tempo di esecuzione di CPU,
mantenendo traccia di differenti sessioni per ogni utente, potendo disporre di memoria centrale virtuale e quindi teoricamente infinita.
Minor successo hanno riscosso i S O d i s t r i b u i t i , ovvero uno speciale sistema informatico in cui il SO riesce a controllare più elaboratori
contemporaneamente conducendoli verso un obiettivo comune, e in cui ogni macchina aumenta la capacità di calcolo complessiva del sistema.
La tecnologia delle reti (LAN e Internet) ha di fatto limitato la rilevanza di questi sitemi, opponendogli i SO multiprogrammati connessi in rete
secondo il modello client/server che raggiunge risultati complessivi molto ragguardevoli e con minori costi.
Di particolare interesse sono ambienti operativi specializzati, come ad esempio i S O e m b e d d e d (sistemi per dispositivi integrati), dedicati a
sistemi mobili come PDA (palmari, smartphone e altro) o a sistemi industriali in real time per il controllo di processi industriali.
S4Abacus – Sistemi Operativi
01-Sistema Operativo.doc.doc - 3 / 5
NOZIONI GENERALI
ELEMENTI TIPICI DI UN SISTEMA OPERATIVO
Gli elementi chiave che caratterizzano un SO sono tradizionalmente individuati nel modo in cui lo stesso gestisce e organizza i suoi costituenti
principali:
• La gestione dei Processi;
• La gestione della Memoria Principale;
• La gestione dei Dispositivi;
• La gestione delle Memorie di Massa;
Tutte queste parti gestionali sono affrontate dal sw del SO nella sua sezione più profonda, denominata K e r n e l (nucleo) del Sistema Operativo.
L’oggetto di studio di questo testo si limita ai SO multiprogrammati, cosicchè in questa fascia di programmi assume una importante rilevanza anche
la gestione dell’interfaccia con l’utente, insieme di programmi di sistema che sono denominati S h e l l (interfaccia) del Sistema Operativo.
Sia le istruzioni contenute nel kernel, che nella shell che in altri moduli del SO sono accessibili ai programmi applicativi tramite S y s t e m C a l l
(chiamate di sistema) che realizzano il sw della API del sistema operativo.
TIPI DI KERNEL
Grande importanza assume attualmente il tipo di architettura con la quale è progettato il nucleo del Sistema Operativo.
Si distinguono tre classi fondamentali di architetture kernel che disegnano le caratteristiche funzionali basilari dell’intero SO.
•
Kernel monolitico
In questo caso le principali funzioni del kernel (processi, memoria, dispositivi) risiedono in uno stesso spazio operativo caricato una volta per tutte
all’avvio del sistema. Il software ad alto livello (applicazioni e applicazioni di SO) chiama direttamente le Api del kernel con un linking
predeterminato. La forte integrazione tra applicativi e kernel assicura un funzionamento molto efficiente in prestazioni ma eventuali blocchi del
kernel in una sua parte compromette tutte le altre parti. Un kernel monolitico risulta essere molto ingombrante, se dovesse prevedere molte gestioni
(es., di periferiche), pertanto alcune versioni prevedono la possibilità di caricare a runtime moduli di kernel per determinate periferiche (es. *nix, a
patto che patto che questi fossero previsti in fase di compilazione del kernel). L’aggiornamento di un kernel monolitico prevede la sua
ricompilazione.
SO a kernel monolitico: MVS, Unix, *nix
•
Microkernel
In questo caso il kernel implementa solo una parte delle funzioni base del SO, e inserisce uno strato aggiuntivo tra nucleo e software applicativo
(modulo server di interfaccia). In questo modo le prestazioni calano, ma la struttura risulta essere modulare, facilmente aggiornabile anche a
runtime e poco vulnerabile ai blocchi: se un modulo server di interfaccia al kernel si blocca non compromette il sistema, ma puo’ essere riavviato.
SO a microkernel: Minix, Mach, QNX, BeOS
•
Kernel ibrido
In questo caso si tratta di nuclei a microkernel con qualche parte di codice in piu’, per aumentare le prestazioni, cercando di aggiungere alla
versatilità del microkernel la velocità di esecuzione di quache parte monolitica ritenuta ‘non essenziale’.
SO a kernel ibrido: Microsoft Nt+, Mac Os X
GESTIONE DEI PROCESSI: MULTIPROGRAMMAZIONE
I SO multiprogrammati riescono a gestire più processi in esecuzione, al contrario dei SO monoprogrammati.
Più programmi in esecuzione contemporaneamente, detti anche p r o c e s s i , consentono all’utente di utilizzare più applicazioni nello stesso tempo e
alla macchina di distribuire il carico computazionale con estrema efficacia, per esempio sulle operazioni di Input/Output verso i dispositivi.
Anche se il calcolatore non dispone di più microprocessori, il SO alterna sulla CPU differenti processi per tempi molto ridotti, rendendo l’esecuzione
dei programmi realmente contemporanea agli occhi degli utenti. L’attività di alternanza dei processi in esecuzione è detta s c h e d u l a z i o n e , i tempi
assegnati ai processi q u a n t i d i t e m p o e il sistema di gestione, t i m e s h a r i n g (condivisione di tempo).
Spesso ogni processo gestito in timesharing si dice eseguito in una m a c c h i n a v i r t u a l e (VT, Virtual Machine), per rendere l’idea che per ogni
singolo processo, il SO mette a disposizione una macchina dedicata, benchè virtuale e non reale. Si ricordi che anche su sistemi multiprocessore, il
numero di processi contemporanei supera sempre il numero di CPU fisiche realmente esistenti.
Ogni programma in esecuzione subisce, durante il suo normale runtime, molti c a m b i d i c o n t e s t o , che sono le operazioni che deve effettuare il
SO per garantire l’alternanza dell’esecuzione dei vari processi. I cambi di contesto sono operazioni di servizio che non contribuiscono
all’avanzamento dei processi, pertanto sono considerati o v e r h e a d per il sistema.
La parte di SO che si occupa della gestione dei processi è chiamata s c h e d u l a t o r e (scheduler), e è costituita da programmi di sistema
fondamentali. Lo scheduler è quindi un programma che risiede nel Kernel del SO.
Nei sistemi operativi moderni il concetto di processo è stato via via sostituito dal concetto di t h r e a d , che ne è equivalente.
Un thread non è altro che un sottoprocesso generato da un processo, cosicchè un processo può essere costituito da più thread. Lo scheduler, in
questi casi, alterna in esecuzione i thread piuttosto che i processi.
La gestione della multiprogrammazione consente ai processi di condividere le risorse del calcolatore e di comunicare tra di loro. La gestione dei
processi si deve quindi occupare anche della sicronizzazione e della c o n c o r r e n z a delle attività verso le risorse e della comunicazione
interprocesso (I P C ).
GESTIONE DELLA MEMORIA: LA MEMORIA VIRTUALE
S4Abacus – Sistemi Operativi
01-Sistema Operativo.doc.doc - 4 / 5
La memoria principale (solo memoria, d’ora in avanti) è il luogo ove il SO e i programmi vengono caricati per avviarli all’esecuzione. La
multiprogrammazione impone che la memoria sia sempre maggiore, in modo da contenere sempre più processi in timesharing.
Per risolvere radicalmente il problema della dimensionie della memoria nei sistemi multiprogrammati, i SO simulano la memoria mancante sulla
memoria di massa (es. disco fisso), cosicchè l’ampiezza della memoria è sempre sufficiente. L’insieme delle tecniche che consentono di simulare la
memoria su disco viene detta m e m o r i a v i r t u a l e .
Naturalmente la memoria su disco è estremamente lenta, così i processi diventerebbero ingestibili. Per ottenere efficienza dal processo di
virtualizzazione della memoria, i SO si servono di tecnologie hardware integrate nelle CPU, denominate M M U (Memory Managmente Unit). Le
principali tecniche di gestione della memoria adottate dai SO sono dette p a g i n a z i o n e e s e g m e n t a z i o n e .
La concorrenza dei processi, poi, obbliga i SO a evitare che i programmi in esecuzione possano inteferire negativamente tra loro, per esempio
sovrapponendosi in memoria. Il gestore della memoria di un SO deve quindi occuparsi di garantire la p r o t e z i o n e d e l l a m e m o r i a per i processi
e per il SO stesso, cercando anche di contrastare anche l’effetto di programmi malintenzionati.
Tutta l’attività del gestore della memoria risiede nel kernel del SO.
GESTIONE DEI DISPOSITIVI: L’I/O
La gestione dei dispositivi o dell’I n p u t / O u t p u t è, da sempre, la parte più critica di ogni sistema operativo.
Le ragioni sono molteplici e, storicamente, fu la gestione delle memorie di massa a rappresentare un notevole blocco nell’evoluzione dei sistemi
informatici (cfr. I/O bottleneck in Storia). La ragione attuale, invece, riguarda la necessità commerciale di avere più produttori di periferiche (terze
parti) spesso diversi dai produttori di calcolatori e dai produttori del SO. Ciò significa che parti consistenti del SO devono essere integrate con
programmi scritti da terze parti (i produttori dei dispositivi) denominati d r i v e r , integrazione che deve essere fatta al livello profondo del SO, cioè a
livello kernel.
L’integrazione tra driver e SO è sempre critico, perché è sufficiente che il driver non rispetti a fondo ogni convenzione adottata dal SO per mettere in
crisi il funzionamento di tutta la macchina. E’ per questo motivo che i moderni SO gestiscono l’I/O tramite tecniche che devono garantire la
p r o t e z i o n e del sistema (analogamente a quanto implementato nella gestione della memoria) separando l’esecuzione dei processi applicativi
u t e n t e dall’esecuzione dei processi di sistema e di gestione dell’I/O in un ambiente p r i v i l e g i a t o .
In base al modo in cui le porzioni software di sistema vengono integrate nel SO, si possono distinguere SO basati su k e r n e l m o n o l i t i c i ,
m i c r o k e r n e l e k e r n e l i b r i d i . Nel primo caso tutti gli elementi di integrazione sono previsti all’interno del nucleo, almeno sottoforma di
chiamate di sistema previste per i moduli aggiuntivi. Nel secondo caso ogni porzione di software di sistema aggiuntiva viene esclusa dal kernel e
aggiunta solo nel momento della sua utilizzazione, nel caso di kernel ibrido un microkernel contiene anche porzioni di codice ‘non essenziale’ che,
posto comunque all’interno del nucleo, rendono il sistema più performante.
In ogni caso la gestione dell’I/O avviene sempre tramite alcune tecniche implementate a livello di architettura fisica, come ad esempio la gestione
dei segnali di i n t e r r u z i o n e h w , delle e c c e z i o n i , dei canali D M A e della consueta lettura e scrittura dei r e g i s t r i nello spazio di
indirizzamento di I/O (cfr. S3Abacus).
La multiprogrammazione, poi, introduce una serie di problematiche sull’accesso delle risorse di I/O denominate u n a r i e (cioè ad uso esclusivo
come una stampante o una periferica di I/O generica): solo un processo alla volta può accedere alla risorsa tramite una serializzazione delle
richieste ottenuta tramite meccanismi di s i c r o n i z z a z i o n e .
GESTIONE DELLE MEMORIA DI MASSA: IL FILE SYSTEM
La gestione delle memorie di massa viene ottenuta da un SO adottando una o più strutture dati denominate F i l e S y s t e m .
Accanto al file system principale adottato, un SO può essere in grado di gestire anche altri modi di leggere e scrivere dati su memorie di massa,
ovvero altri file system adottati da memorie secondarie di altro tipo, come ad esempio CD-DVD Rom, o di altri SO.
I dati residenti fisicamente sulle memorie secondarie sono organizzati in s e t t o r i , a loro volta componenti di elementi logici denominati f i l e s .
Una seconda astrazione serve per organizzare i files tra di loro, tramite d i r e c t o r y per costituire un cosiddetto file system g e r a r c h i c o
organizzato ad albero. Tipici elementi di una organizzazione ad albero è la presenza di una r o o t d i r e c t o r y (directory radice), di nomi completi di
files (p a t h n a m e , percorso più nome logico) e di d i r e c t o r y c o r r e n t e .
L’organizzazione gerarchica ad albero di directory è oramai uno standard per quasi tutti i file system moderni, organizzazione che è implementata
con strutture dati basate su liste concatenate, denominate b * T r e e o strutture dati denominate i - N o d e , che servono soprattutto per velocizzare il
processo di ricerca degli elementi logici (files e directory) sui dispositivi di memorizzazione.
Files e directory contengono, oltre alle informazioni coerenti che li compongono, numerose altre informazioni per regolarne l’accesso da parte degli
utilizzatori (d i r i t t i d i a c c e s s o in base a A C L , Access Control List) o per specificarne la natura operativa (b i t r w x , elementi a sola lettura,
scrittura o esecuzione).
Le chiamate di sistema che un SO offre agli applicativi tramite le API si basano quasi sempre sulla nozione di h a n d l e , che è il riferimento simbolico
associato ad un elemento logico (file o directory) su cui si desidera intervenire con le classiche operazioni consentite: lettura, scrittura, creazione,
eliminazione e modifica.
Numerose, infine, sono le tecniche adottate dai SO attraverso l’uso di file system, per garantire la sicurezza e l’integrità dei dati sui supporti di
memorizzazione, in caso di azioni malevoli o a causa di guasti. In questi casi i file system adottano tecniche di c r i t t o g r a f i a dei dati nel primo
caso, tecniche di r i d o n d a n z a (RAID) per la gestione dei supporti.
LA SHELL
Ogni sistema operativo offre un ambiente di lavoro detto S h e l l che consente all'utente, tra le altre cose, di accedere inizialmente al sistema tramite
un meccanismo di autenticazione (l o g i n ), o di interrompere l’attività del sistema impostandone la terminazione (l o g o f f e/o s h u t d o w n ).
La shell definisce l'interfaccia principale tra l’utente e il sistema operativo.
L'interfaccia a caratteri realizzata da quasi tutti i SO è detto p r o m p t della shell, ed essa possiede come dispositivi standard di input la console
(tastiera) e standard di output lo schermo (monitor).
Essa è in grado di rendere operativo l'utente, cioè di consentirgli di lanciare i processi (sw applicativo e di sviluppo), essendo in grado di interpretare
una serie di chiamate al sistema attraverso un processo di SO fondamentale detto i n t e r p r e t e d e i c o m a n d i .
Grande successo hanno avuto e continuano a ottenere le shell grafiche (G U I ) che consentono all’utente di avviare i processi con meno impegno
mnemonico e più velocemente, supportati da istruzioni iconiche che avviano automaticamente il caricatore del SO per gli applicativi selezionati con
l’input classico di una GUI, ovvero il mouse.
I SO spesso suddividono la shell in vari nuclei per proteggere l'attività del sistema, assegnando a ogni utente o a volte a interi processi la possibilità
di operare solo a particolari gradi di shell.
S4Abacus – Sistemi Operativi
01-Sistema Operativo.doc.doc - 5 / 5
La shell si può vedere anche come un processo di SO il cui compito sostanziale è quello di creare processi figli richiesti dall'utilizzatore e riprendere
il controllo una volta terminata l'esecuzione del figlio. Spesso le shell possono creare processi in background, riprendendo così immediatamente il
controllo della situazione, processi denominati in gergo, s e r v i z i o d e m o n i .
Tramite la shell si possono integrare applicativi utente al SO, soprattutto nel caso di SO a kernel ibrido o gestire automatismi anche complessi
tramite particolari files programmati denominati s c r i p t d i s h e l l .