Domande di Teoria di Sistemi Operativi

Nucleo di un sistema a processi: symmetric multi processing e modello a nuclei distinti e la realizzazione dei semafori

Modello SMP

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 nella coda dei processi pronti e scheduli quello risvegliato.

Modello a kernel distinti

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-rappresentantecessore, e quelli condivisi tra nodi distinti.

Viene innanzitutto introdotto il rappresentante del processo 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 rappresentante viene aggiunto alla coda globale del semaforo.

Quando viene eseguita una V su un semaforo 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, paravirtualizzazione e Xen

Problemi dei ring

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 all’hardware o la gestione delle interruzioni, ring deprivileging, e al contempo si trova al ring 1 come le applicazioni causando quindi problemi di protezione della memoria, ring 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 istruzioni privilegiate tramite l’approccio trap-and-emulate: il sistema guest esegue comunque l’istruzione, 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.

Paravirtualizzazione

La paravirtualizzazione risolve il problema delle istruzioni privilegiate in maniera diversa introducendo le hypercall API.

Ogni volta che il sistema guest deve eseguire un’istruzione privilegiata invece eseguirà la chiamata al VMM attraverso l’hypercall corrispondente, avendo quindi un’interfaccia virtuale diversa da quella fisica; questo richiede la ricompilazione e il porting dei sistemi guest.

Xen

Xen è un VMM che lavora con la paravirtualizzazione mettendo il VMM, noto con il nome di hypervisor, al ring 0, i guest al ring 1 e le applicazioni al ring 3.

Xen permette l’esecuzione diretta delle istruzioni da parte delle VM, dette domains, 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 domain ha in esecuzione un balloon process che, comunicando direttamente con Xen, può richiedere 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’indirizzo di memoria che l’ha causato.

Per avere più indipendenza dall’hardware i driver risiedono nel domain 0, una VM privilegiata che controlla l’intera architettura, e prendono il nome di back-end drivers; le VM vi hanno accesso attraverso un’interfaccia leggera detta front-end drivers 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

Caduta nello stato di working

In caso di caduta nello stato di working, quando il sistema riparte da dove capisco che devo abortire?

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

Lo stato di ready è necessario al fine di garantire la proprietà del tutto o niente nei sistemi multiprocesso, infatti tutti i processi devono aver fatto la commit affinché tutti possano transitare nello stato di committing.

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 centrale