Che materia stai cercando?

NACHOS - Appendice Appunti scolastici Premium

Appunti di Sistemi Operativi del prof. Mazzeo su NACHOS - Appendice: Panoramica, La Struttura di Nachos, le Esercitazioni (Gestione dei Thread e Sincronizzazione, File System, Multiprogrammazione, Memoria Virtuale, Networking), Informazioni su Come Ottenere una Copia di Nachos, Sintesi.

Esame di Sistemi operativi docente Prof. A. Mazzeo

Anteprima

ESTRATTO DOCUMENTO

durante il cambio di contesto da un thread verso un altro, dalla prospettiva di un osservatore

esterno e dei thread coinvolti. Crediamo che questa esperienza sia fondamentale per

demistificare la concorrenza. Precisamente, dato che il C ed il C++ non permettono a nulla

di essere nascosto sotto il tappeto, la concorrenza potrebbe essere più semplice da capire (ma

più difficile da utilizzare) in questi linguaggi di programmazione rispetto ad altri

esplicitamente progettati per la concorrenza, come Ada o Modula-3.

Secondo, un sistema di thread funzionante, come quello in Nachos, fornisce

l’opportunità di impratichirsi nello scrivere e testare programmi concorrenti. Perfino i

programmatori più esperti trovano difficile pensare in concorrenza. La prima volta che

Nachos è stato usato, abbiamo omesso numerosi problemi pratici che ora includiamo

nell’esercitazione, pensando che gli studenti vedessero abbastanza concorrenza nel resto del

progetto. Successivamente, abbiamo capito che molti studenti continuavano a fare errori

riguardo la concorrenza anche nelle fasi finali del progetto.

Il nostro primo obiettivo nella costruzione del sistema dei thread di base è stato la

semplicità, per ridurre gli sforzi richiesti per seguire il comportamento dello stesso.

L’implementazione richiede circa 10 pagine di C++ ed una pagina di codice MIPS

assembly. Per semplicità, il thread scheduling è normalmente non-preemptive, ma per

enfatizzare l’importanza delle sezioni critiche e della sincronizzazione, abbiamo inserito una

opzione da riga di comando che permette di rendere i thread time sliced in punti “casuali”,

ma ripetibili, del programma. I programmi concorrenti sono corretti solo se funzionano

perfettamente quando un cambio di contesto può accadere in qualsiasi momento.

D.3.2 File System

I file system reali sono molto complessi. Il file system UNIX ha, per esempio, almeno tre

livelli di indirezione – la tabella dei descrittori di file per-processo, la tabella di sistema dei

file aperti e la tabella in-core degli inode – prima di arrivare i blocchi del disco. Per rendere

il file system sufficientemente semplice da leggere e capire in poche settimane, siamo stati

obbligati a fare alcune difficili scelte su dove sacrificare il realismo.

Forniamo un semplice file system base funzionante, ripulito di quante più

funzionalità possibile. Anche se il file system ha una interfaccia simile a quella di UNIX

(cast in termini di oggetti C++), ha anche molte significative limitazioni rispetto ai file

system commerciali. Non vi è alcuna sincronizzazione (solo un thread alla volta può

accedere al file system). I file hanno una grandezza massima molto piccola ed hanno una

grandezza fissa una volta creati. Non vi è caching o buffering dei dati dei file. Lo spazio dei

nomi dei file è completamente piatto (non vi è alcuna rappresentazione gerarchica delle

cartelle). In fine, non abbiamo provato a fornire robustezza in caso di crash di macchine e

dischi. Come risultato, il file system di base occupa circa 15 pagine di codice.

L’esercitazione prevede:

1. Correggere alcune di queste limitazioni

2. Migliorare le prestazioni del file system risultante

Abbiamo mostrato poche possibili ottimizzazioni, come caching e scheduling del disco, ma

parte dell’esercizio è decidere quali soluzioni sono più redditizie.

A livello hardware, forniamo un simulatore del disco, che accetta richieste di lettura

e scrittura di settori del disco e segnala la fine dell’operazione attraverso una interruzione. I

dati del disco sono memorizzati in un file UNIX; le operazioni di lettura e scrittura di settori

del disco sono effettuate usando le normali funzioni UNIX di lettura e scrittura da file. Una

volta che il file UNIX è stato aggiornato, calcoliamo quanto sarebbe dovuta durare

l’operazione simulata (dalla traccia e settore della richiesta), e definiamo una interruzione

Traduzione a cura di Dexter - dexterp37@gmail.com 7

che accadrà dopo quel lasso di tempo. Le richieste di lettura e scrittura di settori (che

emulano l’hardware) ritornano immediatamente; il software di alto livello è responsabile per

l’attesa dell’interruzione.

D.3.3 Multiprogrammazione

Nella terza esercitazione, forniamo il codice per creare uno spazio degli indirizzi utente, per

caricare in memoria utente un file Nachos che contiene un’immagine dell’eseguibile, per poi

eseguire il software. Il codice iniziale è limitato all’esecuzione di un solo programma utente

alla volta. L’esercitazione ha come obiettivo di espandere questa base con il supporto per la

multiprogrammazione, di implementare una varietà di system call (come fork ed exec in

UNIX) come anche una shell a livello utente, e di ottimizzare le prestazioni del sistema

risultante in un carico misto di jobs I/O e CPU-bound.

Anche se forniamo una piccola porzione del codice del kernel Nachos come parte di

questa esercitazione, la simulazione hardware richiede una buona quantità di codice.

Simuliamo l’intero set di istruzioni intere MIPS R2/3000 ed un semplice schema di

traduzione della tabella delle pagine ad un livello (per questa esercitazione, l’intero spazio

virtuale degli indirizzi del programma deve essere mappato nella memoria fisica; la vera

memoria virtuale è lasciata per la prossima esercitazione). Inoltre, forniamo una astrazione

che nasconde la maggior parte dei dettagli del formato MIPS object-code.

Questa esercitazione richiede alcuni salti concettuali, ma lega insieme il lavoro delle

due precedenti esercitazioni, risultando in un sistema operativo – seppur limitato –

funzionante. Dato che il simulatore è in grado di eseguire programmi in C, è facile scrivere

software di utilità (come una shell o il comando UNIX cat) per testare il sistema (uno

studente molto ambizioso ha provato ad effettuare un porting di emacs senza risultati).

L’esercitazione illustra che scrivere codice utente non è molto difficile da scrivere codice del

kernel del sistema operativo, sennonché il codice utente risiede in un suo spazio di indirizzi,

isolando il kernel da errori dell’utente.

Un importante argomento che abbiamo scelto di lasciare fuori (ancora, per una

questione di limiti di tempo) è quello che riguarda la tendenza verso sistemi operativi a

small-kernel, dove pezzi del sistema operativo sono divisi in server a livello utente. Grazie

al design modulare di Nachos, sarebbe semplice migrare verso una struttura small-kernel,

tranne che per:

1. Non abbiamo supporto per il debugging simbolico di programmi utente

2. Servirebbe un compilatore stub per rendere agevole l’uso di RPC attraverso

diversi spazi di indirizzi

Un motivo per utilizzare un design a microkernel è indubbiamente quello della semplicità di

debugging del codice di sistema operativo a livello utente invece di codice che è parte del

kernel. Dato che Nachos viene eseguito come un processo UNIX, è valido il contrario: è più

facile sviluppare e debuggare il codice del kernel Nachos rispetto al codice di una

applicazione che viene eseguita da Nachos.

D.3.4 Memoria Virtuale

La quarta esercitazione prevede di rimpiazzare il semplice sistema di gestione della memoria

dell’esercitazione precedente con un vero sistema a memoria virtuale – un sistema che

mostra ad ogni programma utente l’astrazione di una (quasi) infinita memoria virtuale

usando la memoria principale come cache della memoria di massa. Non forniamo alcun

nuovo hardware o componenti di sistema operativo per questa esercitazione.

Traduzione a cura di Dexter - dexterp37@gmail.com 8

L’esercitazione comprende tre parti. La prima parte tratta l’implementazione del

meccanismo per la gestione del page-fault – il kernel deve intercettare il page-fault, trovare

la pagina richiesta sul disco, trovare una pagina in memoria per contenerla (scrivendo il

vecchio contenuto della pagina di memoria su disco se la pagina era in uso), leggere la

nuova pagina dal disco in memoria, aggiornare la voce nella tabella delle pagine e poi

continuare l’esecuzione del programma. Questo meccanismo può avvantaggiarsi del codice

scritto per le precedenti esercitazioni: la memorizzazione dello spazio degli indirizzi può

avvenire semplicemente utilizzando i file Nachos mentre la sincronizzazione è richiesta in

caso di page-fault multipli concorrenti.

La seconda parte dell’esercitazione riguarda l’ideazione di una strategia per gestire la

memoria come una cache – per decidere quali pagine scaricare su disco quando del nuovo

spazio è richiesto, in che circostanze (se ci sono) fare read-ahead, quando scaricare le pagine

piene non usate su disco e quante pagine caricare prima di eseguire un programma.

Queste questioni strategiche possono avere un grande impatto sulle prestazioni

generali del sistema, in parte a causa della differenza tra velocità della CPU e latenza del

disco – questa differenza è aumentata di due ordini di grandezza solo nella scorsa decade.

Sfortunatamente, le strategie più semplici spesso hanno prestazioni inaccettabili.

Per incoraggiare strategie realistiche, la terza parte dell’esercitazione consiste nel

misurare le prestazioni del sistema di paginazione con un programma di moltiplicazione tra

matrici, le quali non entrano in memoria. Questo carico non è rappresentativo del

comportamento del sistema di paginazione nel mondo reale, ma è abbastanza semplice per

illustrare l’influenza delle strategie sulle prestazioni delle applicazioni. Inoltre, il programma

mostra molti dei problemi che si presentano con il caching: piccoli cambiamenti

nell’implementazione possono avere grandi impatti sulle prestazioni.

D.3.5 Networking

La ciliegina sulla torta del progetto è scrivere una importante ed interessante applicazione

distribuita. Abbiamo incluso questa componente del networking dato che le applicazioni

distribuite stanno diventando, giorno dopo giorno, sempre più importanti commercialmente.

A livello hardware, ogni processo UNIX che esegue Nachos rappresenta una

macchina a singolo processore. Simuliamo il comportamento di una rete di macchine

eseguendo molteplici copie di Nachos, ognuna nel suo processo UNIX, ed usando i socket

UNIX per passare i pacchetti tra le “macchine” Nachos. Il sistema operativo può comunicare

con gli altri sistemi inviando pacchetti attraverso questa rete simulata; la trasmissione

avviene attraverso le funzioni send e receive dei socket. Il network Nachos fornisce la

possibilità di trasmissione non sicura di pacchetti dalla grandezza limitata da una macchina

all’altra. La possibilità che dei pacchetti vengano persi (dropped) può venire settata

attraverso la riga di comando, ed il seed può venire usato per determinare quali pacchetti

sono “casualmente” scelti per essere persi. I possono essere persi ma mai corrotti, quindi il

checksum non è richiesto.

Per illustrare come usare il network ed, allo stesso tempo, illustrare i benefici della

stratificazione (layering), il kernel Nachos è provvisto di un semplice protocollo post-office

modellato sopra il network. Il layer post-office fornisce una serie di caselle postali che

dirigono i pacchetti al thread in attesa appropriato. I messaggi inviati attraverso il post-office

contengono un indirizzo di ritorno che può essere usato per l’acknowledgement.

L’esercitazione richiede come prima cosa di implementare un sistema di trasmissione

sicuro (reliable) di pacchetti di grandezza arbitraria, e poi di costruire una applicazione

distribuita su questo servizio. Il supporto per la trasmissione di pacchetti dalla grandezza

arbitraria è dalla semplice implementazione – si deve semplicemente suddividere qualsiasi

pacchetto troppo grande in pacchetti più piccoli dalla grandezza fissa, aggiungere numeri di

Traduzione a cura di Dexter - dexterp37@gmail.com 9

serie alle sezioni, ed inviare tutto pezzo per pezzo. Assicurare la sicurezza (reliability) è più

interessante, richiede una attenta analisi e progettazione. Per ridurre il tempo richiesto per

l’esercitazione, non chiediamo di implementare un controllo di congestione né un window

management, anche se ovviamente queste cose sono importanti nella progettazione di un

protocollo.

La scelta su come completare il progetto è lasciata aperta. Diamo solo alcuni

suggerimenti: UNIX talk multi-utente, un file system distribuito con caching, una struttura

di migrazione dei processi, memoria virtuale distribuita, un protocollo di gateway resistente

ai crash delle macchine. Probabilmente, l’applicazione più interessante che uno studente ha

scritto (di cui noi sappiamo) è stata una versione distribuita della “battaglia navale”, con

ogni giocatore su una “macchina” diversa. Questa applicazione illustrava il ruolo dello stato

distribuito, dato che ogni macchina manteneva solo la sua vista locale della tavola di gioco;

ha inoltre esposto molti problemi di performance nella simulazione hardware, che abbiamo

risolto. Probabilmente, la più grande limitazione dell’implementazione attuale è che non

sono state modellate le prestazioni del modello network correttamente, perché non

manteniamo i timer di ogni macchina Nachos sincronizzati tra di loro. Stiamo lavorando per

risolvere questo problema, usando tecniche di simulazione distribuita per questioni di

efficienza. Queste tecniche ci permetteranno di effettuare paragoni di prestazioni tra

differenti implementazioni del protocollo di network; ci permetteranno inoltre di usare il

network Nachos come una simulazione di un multi-processore passa messaggi (message-

passing).

Informazioni su Come Ottenere una Copia di Nachos

D.4 E’ possibile ottenere una copia di Nachos attraverso il servizio di FTP anonimo della

macchina ftp.cs.berkeley.edu seguendo i seguenti passi:

1. Utilizzare il comando ftp di UNIX per accedere a ftp.cs.berkeley.edu:

ftp ftp.cs.berkeley.edu

2. Verrà richiesto di effettuare il login. Inserite la parola “anonymous” e poi usate il vostro

indirizzo email come password.

Name: anonymous

Password: tea@cs.berkeley.edu (for example)

3. Adesso siete nell’ftp. Entrate nella cartella Nachos.

ftp> cd ucb/nachos

4. Ricordate di settare la modalità binaria nell’ftp; sfortunatamente, nel caso lo

dimenticaste, durante lo scaricamento del file non otterrete alcun messaggio di errore.

Questo tipo di errore è molto comune tra le persone che scaricano software attraverso ftp

anonimi. ftp> binary

Traduzione a cura di Dexter - dexterp37@gmail.com 10

5. Potrete finalmente copiare il file tar UNIX compresso contenente la distribuzione

Nachos per la vostra macchina. Il software vi iscriverà automaticamente ad una mailing

list dalla quale riceverete informazioni riguardo le nuove release di Nachos; potete

cancellarvi dalla mailing list semplicemente inviando una mail a

nachos@cs.berkeley.edu. ftp> get nachos.tar.Z

6. Uscite dal programma ftp: ftp> quit

7. Decomprimente il file per ottenere la distribuzione Nachos. (se la decompressione

fallisce, probabilmente avete dimenticato di settare la modalità binaria nel passo 4.

Eseguite la procedura da capo).

uncompress nachos.tar.Z

tar –xf nachos.tar

8. Il passo precedente produrrà molti file, incluso il codice per il kernel base di Nachos, il

simulatore hardware, la documentazione sulle esercitazioni, e la guida sul C++. Ci sarà

anche un file README per iniziare: spiega come compilare il sistema di base, come

stampare la documentazione e quali architetture sono attualmente supportate.

cat README

Mendel Rosenblum a Stanford ha effettuato il porting del kernel Nachos per

macchine Sun SPARC, anche se i programmi utente costruiti su Nachos necessitano ancora

di essere compilati per processori MIPS R2/3000 RISC. Porting verso macchine che non

sono DEC MIPS UNIX o Sun SPARC sono in lavorazione. Informazioni aggiornate sono

disponibili nel file di README presente nella distribuzione. La dipendenza dalla macchina

si delinea in due modi. Primo, il kernel Nachos viene eseguito come normale codice

applicativo su una macchina UNIX, ma una piccola quantità di codice assembly è necessaria

nel kernel Nachos per implementare il cambio di contesto dei thread. Secondo, Nachos

simula l’esecuzione istruzione per istruzione dei programmi utente, per gestire i page fault e

le altre eccezioni. Questa simulazione si basa sul set di istruzioni MIPS R2/3000. Per

migrare Nachos verso una nuova macchina, bisogna sostituire il codice del kernel per il

cambio di contesto dei thread con codice specifico alla macchina, e dipendere da un C cross-

compiler per generare MIPS object code per ogni programma utente (un cross-compiler è un

compilatore che genera codice oggetto per un tipo di macchina mentre è eseguito su un tipo

differente di macchina). Dato che utilizziamo un cross-compiler, non abbiamo bisogno di

riscrivere il set di istruzioni per ogni nuova macchina. La versione SPARC di Nachos, per

esempio, contiene le istruzioni su come cross-compilare per MIPS su una macchina SPARC.

Le domande riguardo Nachos e le segnalazioni di bug possono essere inoltrate via

email all’indirizzo nachos@cs.berkeley.edu. Le domande possono inoltre essere postate al

newsgroup alt.os.nachos.

Traduzione a cura di Dexter - dexterp37@gmail.com 11


PAGINE

12

PESO

183.59 KB

PUBBLICATO

+1 anno fa


DETTAGLI
Corso di laurea: Corso di laurea in ingegneria informatica
SSD:
A.A.: 2013-2014

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher valeria0186 di informazioni apprese con la frequenza delle lezioni di Sistemi operativi e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Napoli Federico II - Unina o del prof Mazzeo Antonino.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Sistemi operativi

Sistemi Operativi
Dispensa
Sistemi Operativi
Dispensa
Sistemi operativi - schema suntivo per la prova pratica
Appunto
Tesine sui sistemi operativi
Appunto