Continuiamo oggi la nostra carrellata di modelli dei sistemi operativi.
Una generalizzazione dell’ultimo approccio visto alla
fine della scorsa lezione è costituita dai modelli a strati,
che adottano una stratificazione più “spinta” del
sistema operativo in una gerarchia organizzata in un certo numero
n di livelli.
Un livello rappresenta un oggetto astratto che incapsula dati
e operazioni sui dati, fornendo un’interfaccia accessibile
solo al livello superiore.
Sebbene questo modello rappresenti un ottimo strumento di progettazione
software, la struttura risultante può rivelarsi piuttosto pesante
ed inefficiente; inoltre è stato verificato che una stratificazione
pura non è fattibile a causa della complessità di interazioni
che coinvolgono le procedure del kernel.
Per questi motivi in passato si è cercato di limitare il numero
dei livelli, ma attualmente non vengono più progettati sistemi
operativi che implementino questo modello.
E’ doveroso, comunque, ricordare il primo SO che adottò
questo schema, il THE realizzato in Olanda nel 1968 dal prof.
Dijkstra (famoso, tra le altre cose, per aver formulato il classico
“problema dei filosofi affamati”) e lo sfortunato
MULTICS (v. al riguardo la lezione 6).
L’idea di spostare codice del kernel verso livelli superiori
viene estremizzata dal modello a microkernel o a kernel
minimo, che estrae dal nucleo del sistema le funzioni di
gestione lasciandovi solo un numero limitato di compiti di base.
I sistemi a microkernel si suddividono ulteriormente in due
classi:
1) sistemi orientati alle procedure;
2) sistemi client-server.
Il modello orientato alle procedure consente ai processi
utente di gestire e manipolare delle risorse condivise invocando
delle apposite funzioni di gestione, separate dal nucleo del
SO e indipendenti dal firmware del sistema.
Questo modello assume implicitamente che i processi dispongano
di una memoria condivisa, per cui si rendono indispensabili
dei meccanismi di sincronizzazione dei processi per l’accesso
alle strutture dati condivise e degli strumenti di protezione
per evitare interferenze non volute.
Il vantaggio principale di questo modello è l’alta modularità
e portabilità, ma il vincolo di avere architetture a memoria
comune e i conseguenti sforzi per sincronizzare e proteggere
i processi ha portato i progettisti a preferire sistemi client-server.
Il modello client-server implementa la maggior parte
delle funzioni del SO attraverso processi utente, che controllano
l’accesso alle risorse.
Per richiedere un servizio un processo utente (detto processo
client) spedisce un’esplicita richiesta ad un processo
server, che esegue il servizio per conto del client e gli
restituisce la risposta.
In questo schema è il kernel ad occuparsi della gestione della
comunicazione tra client e server.
Il modello client-server offre gli stessi vantaggi di modularità
e portabilità del modello orientato alle procedure, ma poiché
non richiede una memoria comune permette di adottare meccanismi
di protezione più robusti; per questo stesso motivo questo modello
si adatta molto bene ad ambienti distribuiti.
Il modello client-server è molto utilizzato nei sistemi operativi
di ultima generazione come Windows NT e QNX e rappresenta una
delle soluzioni più adottate dai progettisti di nuovi sistemi,
sia centralizzati che distribuiti.
Non è tuttavia esclusa la possibilità di adottare schemi ibridi
che utilizzino entrambi i modelli al di sopra di un kernel minimo;
tale soluzione impegna comunque ad adoperare tecniche “ad
hoc” per sincronizzare e proteggere tutti i processi.
Infine, l’ultimo modello che esamineremo è quello a macchine
virtuali, il cui rappresentante più noto è il sistema IBM
VM/370.
Nei modelli precedenti, la multiprogrammazione e il time-sharing
sono gestiti astraendo solamente il concetto di processo.
Il sistema IBM VM/370 utilizza invece un approccio totalmente
differente: il nucleo implementa una serie di macchine virtuali
da associare ad ogni utente e ciascuna macchina virtuale fornisce
la visione di una macchina fisica dedicata identica a quella
reale.
Poiché il kernel realizza solo l’astrazione di più macchine
fisiche, ciò comporta la necessità di eseguire altri SO al di
sopra delle macchine virtuali; inoltre i SO scelti da utenti
diversi possono anche essere distinti.
L’approccio delle macchine virtuali offre una separazione
completa tra le attività dei vari utenti, perché non esiste
nessuna possibilità di interazione tra macchine virtuali distinte.
Sebbene il VM/370 abbia avuto scarso successo, il modello a
macchine virtuali è stato comunque “riutilizzato”
in diversi contesti dove la protezione e’ essenziale (emulatori,
ambienti NT o Mach, Java VM).
Torna all'indice Generale del corso di Corso di Sistemi Operativi di Software Planet