Multics

Multics (Multiplexed Information and Computing Service) fu uno dei primi sistemi operativi in condivisione di tempo, sviluppato attivamente a partire dal 1964. Nella sua concezione originale avrebbe dovuto servire le necessità di calcolo dell'intera città di Boston, similmente ad un servizio di distribuzione di elettricità o acqua corrente.

Multics sistema operativo
Logo
Sviluppatore	MIT, GE, Bell Labs
Release corrente	ultimo anno di sviluppo (1985)
Tipo di kernel	Seme monolitico
Piattaforme supportate	GE-645 e Honeywell 6180 series
Tipo licenza	Software libero con controparti proprietarie
Licenza	Licenza MIT
Stadio di sviluppo	Stabile, Storico
Successore	Unix
Sito web	Multicians e sorgenti

Multics mise sul campo tutta una serie di concetti e tecniche costruttive che sono ancora oggi elementi essenziali dei moderni sistemi operativi. Il sistema venne modificato nell'arco degli anni seguenti per essere usato su varie macchine.

Nell'ottobre del 2007 il MIT ha deciso di rendere pubblico il codice sorgente del sistema operativo.

Il nome del sistema operativo Unix nacque in contrapposizione a Multics.

Filosofia e storia

Lo sviluppo di Multics inizia nel 1964 al Project MAC. Viene presentato per la prima volta nel 1965 alla Fall Joint Computer Conference, tramite una serie di sei seminari:

• "Introduction and Overview of the Multics System", F. J. Corbató e V. A. Vyssotsky
• "System Design of a Computer for Time-Sharing Applications", E. L. Glaser, J. F. Couleur, e G. A. Oliver
• "Structure of the Multics Supervisor", V. A. Vyssotsky, F. J. Corbató, e R. M. Graham
• "A General Purpose File System for Secondary Storage", R. C. Daley e P. G. Neumann
• "Communications and Input/Output Switching in a Multiplex Computing System", J. F. Ossanna, L. Mikus, e S. D. Dunten
• "Some Thoughts About the Social Implications of Accessible Computing", E. E. David, Jr. e R. M. Fano

Scopi principali

In “Introduction and Overview of the Multics System”, di Corbató e Vyssotsky, tra gli scopi principali di Multics troviamo:

• Orientato all'uso tramite terminali remoti
• Disponibilità continua analoga ai servizi elettrici e telefonici
• Ampia possibilità di configurare il sistema, senza riorganizzare l'architettura
• Alta affidabilità del file system
• Supporto per la condivisione delle informazioni
• Supporto di molte applicazioni
• Supporto di diversi linguaggi di programmazione
• Possibilità di aggiornare il sistema in base all'evoluzione tecnologica e alle aspirazioni degli utenti

Quindi tra gli scopi principali del progetto troviamo l'abilitazione di utenti remoti all'utilizzo di un computer, ed è per questo che il time-sharing è una delle caratteristiche fondamentali del sistema: permette cioè a più utenti di utilizzare interattivamente lo stesso computer. Diviene importante quindi anche la sicurezza e la riservatezza dei dati degli utenti.

Oltre a questi aspetti prettamente tecnici, lo scopo maggiore del progetto era sottolineare l'importanza della progettazione di un'architettura. Nello sviluppo di Multics si teneva sempre in considerazione questi tre punti:

1. Progettare prima di implementare
2. Utilizzare un sistema time-sharing
3. Utilizzare un linguaggio ad alto livello per tutte le funzioni indipendenti dall'hardware

Sviluppo e commercio

Allo sviluppo di Multics lavorarono tre enti: MIT, Bell Labs e General Electric. Le scelte politiche riguardanti il progetto venivano prese dalla “Trinità”, composta da tre persone provenienti dai tre diversi enti:

• Roberto Mario Fano (MIT)
• Edward E. David (BTL)
• John Weil, poi Eugene White, poi C. Walker Dix (GE)

Le scelte tecniche erano gestite dal “Triumvirato”, la cui prima formazione era:

• Fernando J. Corbató (MIT)
• Ed Vance (GE)
• Vic Vyssotsky (BTL)

Mentre l'ultima fu:

• Fernando J. Corbató (MIT)
• A. L. Dean (GE)
• Peter G. Neumann (BTL)

Jerome H. Saltzer e Edward L. Glaser furono consulenti del “Triumvirato”.

La prima shell fu sviluppata da Glenda Schroeder.

Nel 1969 i Bell Labs abbandonarono il progetto ritenendolo poco utilizzabile nella pratica. Nel 1970 subentrò così la Honeywell, acquistando la divisione computer della General Electric. La Honeywell commercializzò Multics a partire dal 1973, il prezzo dell'architettura hardware e del sistema operativo era sette milioni di dollari. I siti venduti nei venti anni successivi furono un centinaio.

Lo sviluppo di Multics termina nel 1985 e l'ultima installazione attiva viene definitivamente spenta nell'ottobre del 2000 al Canadian Department of National Defence.

Gestione della memoria

La memoria di Multics è gestita con segmentazione e paginazione. Nella tabella sono riportate le dimensioni delle strutture principali:

processo	massimo 4096 segmenti
segmento	massimo 256 pagine
pagina	1024 parole
parola	36 bit

In Multics i segmenti sono utilizzati per contenere tutte le strutture dati tipiche di un sistema operativo: i programmi, i dati, la pila e i file. Questi ultimi, infatti, nel momento in cui un processo li apre, sono associati ad un segmento e tale segmento farà parte del suo spazio di indirizzamento (la memoria virtuale indirizzata dal processo), ottenendo così la possibilità per il processo di utilizzare il file.

I segmenti sono condivisibili tra processi grazie a strutture dati del kernel. Solo il kernel può avere dei segmenti non associati a file: l'unico modo in cui un utente può creare un segmento è aprire un file, per questo Multics prevede per ogni processo una process directory, cioè una cartella dove può creare segmenti temporanei.

Mentre i segmenti sono una struttura gestibile dai programmatori ad alto livello, le pagine sono invisibili e vengono gestite dal sistema operativo. Multics implementa la classica paginazione su domanda e l'algoritmo utilizzato per la sostituzione delle pagine è LRU, Least Recently Used, approssimato con un bit.

Dynamic Linking

In Multics non esiste un caricatore o loader. Cioè se un processo esegue una funzione esterna, non dichiarata nel suo programma, cerca il segmento dove questa è caricata e lo aggiunge al suo spazio di indirizzamento, in modo da poterla eseguire. Questo viene chiamato dynamic linking e viene realizzato secondo uno schema di fault: se la funzione da eseguire non si trova nello spazio di indirizzamento del processo, abbiamo un linkage fault, il cui handler (funzione apposita per la gestione del fault) provvede a cercare il segmento contenente la funzione desiderata. Se anche questa ricerca fallisce riceviamo un messaggio di fault non eliminabile, altrimenti il processo può eseguire la funzione di cui aveva bisogno.

Gestione dei processi

Negli anni la funzione di scheduling di Multics è stata modificata e nuove caratteristiche sono state aggiunte:

1967	Exponential scheduler
1975	Percentage Scheduler
1975-1976	Deadline Scheduler

Exponential scheduler

L'Exponential scheduler implementa il time-sharing ed è organizzato su code di priorità. Nella terminologia di Multics l'intervallo temporale che caratterizza il time-sharing è detto quanto. Se il processo è ancora in esecuzione al termine del proprio quanto, viene abbassato di priorità e il suo quanto viene raddoppiato (da questo nasce il nome exponential o esponenziale). Questo garantisce l'interattività dei processi più corti rimandando l'esecuzione di quelli che occupano il processore per molto tempo. Questo scheduler viene chiamato Foreground-Background scheduler proprio per il fatto che sposta i processi nelle classi di priorità: dal “primo piano” (foreground) verso lo “sfondo” (background).

Percentage scheduler

In Multics troviamo inoltre il Percentage scheduler, o Workclass scheduler, che organizza i processi dei diversi gruppi di utenti, detti workclass. Ci sono infatti 16 gruppi e ogni utente è parte di uno di questi. L'amministratore del sistema assegna una percentuale di utilizzo del processore ad ogni gruppo e lo scheduler si comporta in modo che la quantità di lavoro effettuata dagli utenti sia proporzionale a questa percentuale.

(EN)

«If a group is assigned 20% of the CPU, then the scheduler attempts to give one out of every five quanta to processes from that group»

(IT)

«Se ad un gruppo è assegnato il 20% della CPU, allora lo scheduler tenta di dare un quanto ogni cinque ai processi di questo gruppo»

(Brian L. Stuart, Principles of operating systems)

Se non ci sono processi pronti per un gruppo allora la loro percentuale viene suddivisa tra gli altri. Il tutto viene fatto tramite un sistema di crediti detti scatter credits, che permettono al sistema operativo di decidere in quale gruppo scegliere il prossimo processo. All'interno di ogni gruppo lo sceduling viene effettuato secondo la politica, detta sopra, del Forground-Background scheduler.

Deadline scheduler

Infine Multics permette di schedulare tramite il Deadline scheduler, definendo per ogni gruppo delle scadenze o “tempi limite” (caratteristica tipica dei sistemi in tempo reale). Si possono quindi ordinare i processi secondo due parametri: il tempo di risposta o il tempo di inizio. Nel primo caso parliamo di scadenza virtuale, si privilegia tra tutti i processi di tutti i workclass quello che terminerà prima. Si dice “virtuale” poiché, a differenza dei sistemi in tempo reale, tale scadenza non è critica, è solo un parametro di ordinamento. L'altro criterio è il tempo di inizio, detto in Multics realtime deadlines. Questo definisce quando un processo passerà in esecuzione ignorando gli altri parametri di scheduling. Questi due aspetti dello scheduler di Multics furono aggiunti da Bob Mullen con due scopi precisi: garantire maggiore efficienza per i processi gestori di periferiche e migliorare le prestazioni di alcuni benchmark.

Ring di protezione

In Multics, per distinguere i privilegi di un processo, invece del classico sistema utente/supervisore, si utilizza una gerarchia con più stati. Un processo può essere eseguito in uno dei diversi rings o anelli: immaginiamo diversi anelli concentrici dove il più esterno rappresenta processi poco privilegiati, mentre l'anello centrale, o ring 0, sarà il più privilegiato. Quindi i diritti di accesso alle risorse del sistema diminuiscono man mano che ci si allontana dal centro. In Multics i primi tre rings sono riservati al sistema operativo, mentre gli altri sono utilizzabili dai processi utente. Tramite i gates (letteralmente "portali"), un processo di un ring più alto può accedere funzionalità concesse a ring più bassi.

Gestione delle periferiche

L'idea centrale della gestione delle periferiche in Multics è quella della modularità, al fine di garantire compatibilità e estendibilità. Il sistema Input/Output di Multics fornisce infatti un'interfaccia indipendente dalle periferiche, che vengono gestite attraverso uno stream Input/Output: tutte le richieste vengono cioè sequenzializzate. Queste successivamente vengono convertite in istruzioni specifiche per ogni periferica da un apposito modulo chiamato DIM, Device Interface Module. Questo converte le richieste da device-independent (indipendenti dalla periferica) in richieste device-dependent (dipendenti dalla periferica). Per farlo, compila un programma per il GIOC (Generalized Input/Output Controller). Il programma compilato rispecchia le particolarità specifiche di ogni periferica, necessarie per il suo utilizzo. Il DIM, ad esempio, deve convertire la codifica dei caratteri usati dal sistema in quella specifica per la periferica: si potevano infatti collegare a Multics differenti tipologie di terminali remoti, ognuno con la propria codifica di caratteri. I diversi DIM e il GIOC interagiscono tramite il GIM, GIOC Interface Module.

Altri progetti

Altri progetti

• Wikimedia Commons

• Wikimedia Commons contiene immagini o altri file su Multics

Collegamenti esterni

• (EN) Sito ufficiale, su multicians.org.
• (EN) Multics, su Enciclopedia Britannica, Encyclopædia Britannica, Inc.
• Repository sorgenti di Multics, su web.mit.edu.
• (EN) Sito dedicato a Multics sul sito del Massachusetts Institute of Technology, su web.mit.edu. (S)

Controllo di autorità	BNF (FR) cb119348359 (data)