Corso di Sistemi Operativi

Modelli di sistemi operativi - Parte II

 

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