Domande di Teoria di Sistemi Operativi

Nucleo di un sistema a processi: Simmetric Multi Processing e

modello a nuclei distinti e la realizzazione dei semafori.

Nel modello SMP i semafori sono mantenuti nella memoria del kernel condiviso supponendo

un’esecuzione parallela delle operazioni come P e V con sequenzializzazione solo al momento

dell’accesso alle code di processi. Il kernel deve tenere in memoria l’informazione su quale sia il

processo meno prioritario in un dato momento per permettere la pre-emption al momento della V

in caso venga risvegliato un processo più prioritario, in questo caso il nodo che ha eseguito la V si

occupa di mandare un interrupt al nodo col processo meno prioritario perché possa spostarlo nel-

la coda dei processi pronti e scheduli quello risvegliato.

Nel caso del modello a kernel distinti ogni nodo esegue un kernel distinto con i propri processi,

per cui i semafori si distinguono in locali al nodo (gestiti quindi come quelli di sistema monopro-

rappresentante

cessore) e quelli condivisi tra nodi distinti. Viene innanzitutto introdotto il del pro-

cesso che permette di individuare il nodo su cui esegue e il suo descrittore all’interno del nodo.

Concentrandosi solo sul caso dei semafori condivisi, quando viene eseguita una P sospensiva il

descrittore del processo viene aggiunto alla coda locale al nodo del semaforo e il suo rappresen-

tante viene aggiunto alla coda globale del semaforo. Quando viene eseguita una V su un semafo-

ro con processi sospesi, il nodo che l’ha eseguita procede ad estrarre il primo rappresentante

(supponendo una gestione FIFO) quindi individua il nodo di appartenenza e gli manda un interrupt

affinché possa estrarre il descrittore dalla coda locale e aggiungerlo a quella dei processi pronti.

La comunicazione avviene attraverso un’area di memoria condivisa tra ogni coppia ordinata di

nodi (corredata da un’indicatore di sincronizzazione che indica se i dati sono validi per essere letti

oppure l’area è pronta per ricevere altri dati).

Virtualizzazione: problemi principali dei ring, paravirtualizza-

zione e Xen.

I problemi principali derivano dal fatto che il sistema operativo guest non si trova più nel ring 0,

di conseguenza non è più in grado di eseguire le operazioni privilegiate come l’accesso al’’hard-

deprivileging)

ware o la gestione delle interruzioni (ring e al contempo si trova al ring 1 come le

compression

applicazioni causando quindi problemi di protezione della memoria (ring o

aliasing). Questi problemi possono essere gestiti con processori dedicati che introducono ring

intermedi tra kernel (ring 0) e user (ora ring 3) in cui collocare il sistema guest, che gestirà le istru-

zioni privilegiate tramite l’approccio trap-and-emulate: il sistema guest esegue comunque l’istru-

zione, la CPU rileva che non viene dal ring 0 e manda un’eccezione al VMM che quindi simula

l’esecuzione dell’istruzione per conto del guest.

La paravirtualizzazione risolve il problema delle istruzioni privilegiate in maniera diversa introdu-

cendo le hypercall API. Ogni volta che il sistema guest deve eseguire un’istruzione privilegiata in-

vece eseguirà la chiamata al VMM attraverso l’hypercall corrispondente, avendo quindi un’inter-

faccia virtuale diversa da quella fisica, questo richiede la ricompilazione e il porting dei sistemi

guest.

Xen è un VMM che lavora con la paravirtualizzazione mettendo il VMM, noto con il nome di hy-

pervisor, al ring 0, i guest al ring 1 e le applicazioni al ring 3. Xen permette l’esecuzione diretta del-

domains,

le istruzioni da parte delle VM, dette che si occupano anche della paginazione della

memoria virtuale delegando a Xen solo il compito di scrivere e aggiornare le tabelle delle pagine

dato che risiedono nella sua area di memoria e quindi ne ha accesso esclusivo, i guest possono

comunque leggerle per efficienza. Affinché Xen possa reclamare memoria per se stesso ogni do-

balloon process

main ha in esecuzione un che comunicando direttamente con Xen può richiede-

re al guest altre pagine e quindi cederle al VMM. Le eccezioni sono gestite direttamente dai guest,

solo il page fault richiede la mediazione di Xen per accedere al registro in cui è contenuto l’indiriz-

zo di memoria che l’ha causato. domain 0,

Per avere più indipendenza dall’hardware i driver risiedono nel una VM privilegiata

back-end drivers,

che controlla l’intera architettura, e prendono il nome di le VM vi hanno acces-

front-end driver

so attraverso un’interfaccia leggera detta che comunica con quelli nel domain 0.

1 di 6

Azioni atomiche multiprocesso: i vari stati e come funzionano,

dove risiede il descrittore dell’azione, copie di lavoro, copie

delle intenzioni, richiesta esclusiva degli oggetti. In caso di ca-

duta nello stato di working, quando il sistema riparto da dove

capisco che devo abortire?

Ogni processo può essere nello stato di working, ready, committing e aborting. Lo stato di ready

tutto o niente

è necessario al fine di garantire la proprietà del (nei sistemi multiprocesso), infatti

tutti i processi devono aver fatto la commit affinché tutti possano transitare nello stato di commit-

ting.

Per tener traccia dello stato di ogni processo si definisce il descrittore dell’azione atomica che

risiede in memoria stabile e non è quindi soggetto a malfunzionamenti. All’inizio dell’azione ogni

co-

processo fa una copia in memoria centra