Sistemi Operativi

Maria Teresa Bombi Appunti sui Sistemi Operativi pag.
1
Sistema Operativo

N.B. Questi appunti sono basati su materiale reperito in rete e liberamente adattato.

Introduzione

Il Sistema Operativo costituito da un insieme di programmi che vengono caricati in memoria
centrale allavvio del sistema (boot). Ha il compito di ottimizzare luso delle risorse del sistema,
prendendone il controllo e assegnandole ai processi. Inoltre funge da interfaccia tra lutente e la
macchina fisica.

Un processo un programma in esecuzione. Il programma unentit passiva: un insieme di byte
contenente la codifica binaria delle istruzioni da eseguire. Il processo unentit attiva, listanza di
un programma in esecuzione. Ogni attivit allinterno del S.O. rappresentata da un processo, che
quindi lunit di lavoro allinterno del sistema.
Una risorsa una entit h/w o s/w necessaria allavanzamento di un processo, le risorse h/w sono il
processore, la memoria centrale e tutte le periferiche di I/O.

Per facilitare luso del computer il SO fornisce diversi servizi:
Sviluppo di software: editor, compilatori, debugger, ecc.;
Esecuzione di programmi;
Accesso ai dispositivi di I/O;
Accesso protetto alle risorse condivise;
Maria Teresa Bombi Appunti sui Sistemi Operativi pag. 2
Gestione degli errori e dei malfunzionamenti;
Gestione di statistiche e raccolta dati per addebiti agli utenti e per monitorare le prestazioni.
Protezione
Multiprogrammazione e multiutenza rendono necessari alcuni meccanismi HW per esercitare la
protezione sulle risorse. Le risorse allocate a programmi/utenti devono essere protette nei confronti
di accessi illeciti di altri programmi/utenti.
Molte architetture prevedono un duplice modo di funzionamento (funzionamento dual mode), che
consente di differenziare due tipi di esecuzione: user mode per i programmi utente e kernel mode
(supervisor, monitor mode) per il sistema operativo.
In questo caso larchitettura h/w prevede un bit di modo (kernel: 0, user: 1). Al verificarsi di
uninterruzione, lhardware commuta al kernel mode.
Le istruzioni privilegiate (operazioni di i/o, operazioni di gestione della memoria, ecc.) possono
essere eseguite soltanto se il sistema si trova in kernel mode. I programmi utente vengono eseguiti
in user mode, se un programma utente tenta lesecuzione di una istruzione privilegiata, viene
generata una trap. Per richiedere lesecuzione di istruzioni i programmi utenti devono effettuare una
supervisor call tramite linvio di uninterruzione software al S.O.
Questa comporta il salvataggio dello stato (PC, registri, bit di stato, etc.) del programma chiamante
e trasferimento del controllo al S.O. Il S.O. esegue in modo kernel loperazione richiesta (gestione
dell'interruzione) e al termine delloperazione, il controllo ritorna al programma chiamante (ritorno
al modo user) La comunicazione tra il programma chiamante ed il sistema operativo avviene
mediante i parametri della system call, normalmente passati tramite registri e/o blocchi di memoria
indirizzati da registri.

Storia dei sistemi operativi.

I S.O. si sono evoluti nel corso degli anni a seconda delle diverse generazioni di calcolatori, dal
momento che, storicamente, sono stati sempre legati allarchitettura dei calcolatori sui quali erano
in esecuzione.
Prima generazione (1945-1955)
Circa verso la seconda met degli anni 40 Howard Aiken e John von Neumann riuscirono a
costruire macchine da calcolo, con rel meccanici poi sostituiti da valvole, ma erano macchine
molto lente e molto costose. Tutta la programmazione veniva fatta in linguaggio macchina (i
linguaggi di programmazione, assembler compreso, non erano ancora conosciuti) e ancora non si
parlava di SO. Le applicazioni erano semplici calcoli numerici.
In tali sistemi non esisteva il SO, veniva eseguito un programma alla volta, i dispositivi di input
erano lettori di schede perforate, gli errori venivano indicati da lampadine e loutput prodotto su
stampanti.
Seconda generazione (1955-1965)
Durante la seconda met degli anni 50 lintroduzione del transistor cambi radicalmente la
situazione e nacquero i primi mainframe. I costi erano ancora notevoli, si utilizzavamo le schede
perforate.
Per evitare sprechi si attu la soluzione dei sistemi batch (letteralmente: a lotti). Un insieme di
lavori (job) veniva caricato nel sistema tramite dispositivi di input quali ad esempio i lettori di
schede. I lavori arrivavano allunit centrale, venivano elaborati uno alla volta e i risultati inviati su
dispositivi di output, ad esempio stampanti.
Poich i dispositivi periferici sono molto pi lenti del processore, a uno stesso elaboratore erano in
genere collegati pi dispositivi di input e pi dispositivi di output, in questo modo era possibile
eseguire un programma di seguito allaltro, senza soste, utilizzando al massimo il processore.
I job erano preceduti da istruzioni espresse in uno specifico linguaggio (JCL, Job Control
Language) che istruivano il sistema sul lavoro da fare (es. compilare un programma, eseguirlo, dove
inviare loutput, quanto tempo di CPU utilizzare al massimo, come contabilizzare i costi
dellelaborazione ecc.). Possiamo pensare al JCL come a un antenato dei linguaggi di shell.
evidente che in questi sistemi non era prevista alcuna interazione tra lutente e la macchina
durante lesecuzione dei lavori (cio, lutente preparava tutto linput del programma e
pazientemente attendeva la stampa dei risultati), per questo motivo attualmente il termine batch
riferito allelaborazione significa non interattiva.
Lelaborazione batch richiedeva un primo rudimentale SO, che inizialmente prese il nome di
monitor. Il monitor caricava i lotti uno un lotto alla volta, il processore alternava lesecuzione
di:istruzioni del monitor (che eseguiva le funzioni comandate dalle schede JCL) e istruzioni del
programma (job).
Per funzionare il monitor pu sfruttava alcune importanti caratteristiche presenti nellhardware:
protezione della memoria, per impedire che un programma utente accedesse alla memoria
del monitor;
timer, per terminare a forza programmi troppo lunghi;
istruzioni privilegiate, ad es. le istruzioni di I/O, per evitare che i programmi leggessero le
schede JCL.

Terza generazione (1965-1980)
I sistemi batch si sono evoluti nei sistemi batch multiprogrammati, con pi programmi in memoria.
Quando il programma in esecuzione chiedeva al SO di eseguire unoperazione di I/O (lenta), il SO
avviava loperazione e, nellattesa che sia completasse, cedeva il controllo ad un altro programma.
Il funzionamento era ancora di tipo batch, ma la produttivit era pi alta, perch il processore era
usato in modo pi efficiente.
Lh/w doveva consentire la gestione dellI/O tramite interruzioni e DMA.
Parallelamente ai sistemi batch multiprogrammati si svilupparono i primi sistemi di tipo time-
sharing (a partizione di tempo). Le modalit di funzionamento non erano pi di tipo batch, gli
utenti usavano un terminale per accedere al sistema in cui venivano eseguiti job interattivi.
Il SO, tramite lo scheduler, eseguiva a turno ciascun programma per un breve intervallo di tempo,
che prende il nome di quanto di tempo (in inglese, time-slice). I tempi di risposta percepiti dagli
utenti erano paragonabili a quelli di un sistema dedicato.

Quarta generazione (1980 - ????)
I sistemi operativi moderni sono unevoluzione dei sistemi time sharing, e vengono chiamati sistemi
interattivi; infatti in tali sistemi si ha una continua interazione tra lutente e il SO.
Sistemi paralleli
Oggi molti sistemi sono basati su un unico processore, ma c la tendenza a realizzare sistemi multi-
processore per aumentare il throughput (lavoro prodotto nellunit di tempo), diminuire il tempo di
esecuzione e aumentare laffidabilit (fault tolerance, graceful degradation).
I sistemi multi processore possono essere:
Simmetrici: tutti i processori sono alla pari e possono condividere dinamicamente processi e
risorse. Tutti i SO moderni, compresi Windows NT e Linux, forniscono il supporto per
SMP;
Asimmetrici: un processore il master, gli altri sono slave che eseguono quanto deciso e
schedulato dal master, normalmente gli slave sono processori di back-end,dedicati ad attivit
specifiche, quali gestione del disco (per stabilire lordine di esecuzione delle richieste di
accesso), gestione della tastiera e simili.
Sistemi real-time
I sistemi real-time sono sistemi che devono rispondere a eventi esterni entro intervalli di tempo
prefissati. Tipicamente sono utilizzati nei sistemi di controllo (processi industriali, esperimenti
scientifici, elaborazioni di immagini mediche, elettrodomestici, missili)
A differenza dei sistemi hard real-time, che devono garantire il rispetto assoluto delle specifiche
temporali, si identificano anche i sistemi soft real-time, che sono veloci, ma non garantiscono il
completamento delle operazioni entro un tempo massimo prefissato. In tali sistemi possibile
definire dei task o dei processi R-T, cui il SO assegna maggiore priorit.
Luso di funzionalit real-time sempre pi diffuso ed presente in molti SO attuali (alcune
versioni di UNIX, Windows NT, ).
Organizzazione dei Sistemi Operativi
La struttura del Sistema Operativo pu essere a strati oppure monolitica.
Organizzazione a strati

Con tale organizzazione ogni strato fornisce dei servizi allo strato che gli sta sopra, usando (e
nascondendo) quelle dello strato che gli sta sotto. Ogni strato quindi realizza un livello di macchina
virtuale.
Lh/w dovr essere dotato di un sistema per le interruzioni h/w, per le interruzioni software
(Supervisor Calls, SVC), di un meccanismo di protezione della memoria, un orologio in tempo reale
(real time clock) e dovr operare in dual mode.
Le funzioni dei livelli sono:
1. Nucleo: si occupa dellI/O di basso livello (handler dei dispositivi) e della gestione della
risorsa processore. Fornisce inoltre delle funzionalit che consentono la sincronizzazione tra
i processi.
2. Gestore della memoria: gestisce la risorsa memoria.
3. Gestore delle periferiche: si occupa dellI/O di alto livello. Unoperazione di I/O ad alto
livello costituita da un insieme di operazioni elementari di I/O.
4. File system: mappa la struttura fisica del disco (sequenza di blocchi) nella sua struttura
logica (organizzazione gerarchica di file e directory).
5. Altre funzioni del Sistema Operativo:
a. Interprete dei comandi: (shell) linterfaccia con la quale lutente interagisce con il
Sistema Operativo, allo stesso livello della shell si trovano le applicazioni che non
utilizzano linterfaccia grafica. Nei sistemi operativi pi recenti, al fianco
dellinterprete dei comandi si trova il gestore delle finestre (es. X-Windows), che
fornisce tutte le funzionalit necessarie alla gestione della GUI.
b. Gestore del desktop: linterfaccia con la quale lutente interagisce con il Sistema
Operativo quando utilizza la GUI, allo stesso livello si trovano le applicazioni che
utilizzano linterfaccia grafica.

Esempio: Architettura di Windows NT

Organizzazione monolitica

Con tale organizzazione solo le funzioni essenziali fornite dal kernel, mentre le altre funzioni sono
affidate a processi (eseguiti in modo supervisore o in modo utente) trattati dal microkernel alla
stregua degli altri processi.
Esempio: architettura del SO Unix

Il nucleo
Come abbiamo gi detto, il nucleo si occupa dellI/O di basso livello, per questo motivo ad esso
appartengono tutte le RSI del sistema. Inoltre il nucleo gestisce la risorsa processore, tramite lo
scheduler e il dispatcher. Infine il nucleo si occupa di gestire la sincronizzazione tra processi,
tramite i semafori con primitive wait e signal.
La gestione delle interruzioni e delle sincronizzazioni tra processi sono strettamente legate alle
gestione del processore (dispatching). Le funzioni legate alla creazione dei processi sono trasversali
(riguardano lallocazione di risorse quali memoria, dispositivi ecc.)
Lhardware fornisce le funzioni di commutazione del contesto (viene salvato il contesto del
programma che viene interrotto), riconoscimento della interruzione (es. sistema di interrupt
vettorizzato) e attivazione della routine di servizio (RSI) appropriata, gestione dei livelli di priorit,
per stabilire quale richiesta di interruzione servire per prima in presenza di pi richieste.
Il First Level Interrupt Handler (FLIH) consente di svolgere in modo (rapido) le 3 funzioni indicate.
Le interruzioni esterne (richieste da dispositivi di I/O) e quelle interne (SVC - Supervisor Call) sono
gestite allo stesso modo. Quando si verifica uninterruzione il processore si porta ad operare in
modo supervisore: le routine di servizio delle interruzioni sono eseguite in modo supervisore.
Scheduler e Dispatcher

In un SO multitasking un processo pu trovarsi nello stato:
Pronto (ready): il processo possiede tutte le risorse che gli sono necessarie per avanzare esclusa
la CPU. In questo stato i processi sono accodati in una lista di processi (ready list - RL). Ogni
volta che il processore si libera, il primo processo della lista va nello stato di esecuzione.
In attesa (waiting): un processo nella sua evoluzione, alterna intervalli di tempo in cui usa la
CPU e intervalli di tempo in cui attende che si completino operazioni di I/O o sincronizzazioni.
In un SO multitasking lo scheduler quando il processo corrente richiede unoperazione di I/O o
di sincronizzazione lo toglie dallo stato di eseguibile e lo porta nello stato di attesa. I processi in
attesa sono accodati in una lista di processi (waiting list - WL). Quando loperazione richiesta
termina, il processo viene accodato nello stato di pronto.
Esecuzione (running): il processo sta utilizzando il processore, in questo stato si pu trovare un
solo processo per ciascun processore presente nel sistema. Il processo rimane in questo stato
fino a che termina, richiede una operazione di I/O oppure scade il suo quanto di tempo.
Nuovo: il processo sta accumulando le risorse che gli consentiranno di passare allo stato di
pronto.
Finito: il processo ha terminato la sua elaborazione e il SO sta riprendendosi le risorse che gli
aveva assegnato.
Il dispatcher (scheduler a basso livello) ha il compito di estrarre tra i processi nella Ready List
quello da far entrare in esecuzione, quindi il dispatcher commuta il contesto. Lo scheduler ad alto
livello modifica le priorit dei processi pronti e in attesa. Lo scheduler ed il dispatcher interagiscono
tra loro per ottenere il risultato voluto secondo la politica adottata.
Il lavoro del dispatcher strettamente correlato al meccanismo di gestione delle interruzioni.
In un sistema monotasking, la routine di servizio di una interruzione (RSI) esegue il servizio
richiesto (ad es. acquisisce un carattere), rimuove la causa che ha generato la richiesta di
interruzione, esegue listruzione di ritorno da interrupt, che ripristina il contesto del programma che
era stato interrotto, il quale pu quindi proseguire la sua esecuzione.
In un sistema multitasking il servizio di una interruzione pu comportare invece la modifica dello
stato di un processo (ad es. da attesa a pronto); le RSI terminano cedendo il controllo allo scheduler
(anzich al processo interrotto); lo scheduler decide (in base alla politica adottata) se far proseguire
il processo che era stato interrotto, o se portare in esecuzione un altro processo (scelto tra quelli
pronti, ponendo nello stato pronto quello interrotto).
Il descrittore di processo (PD: Process Descriptor, o anche PCB: Process Control Block) una
struttura di dati che contiene informazioni associate al processo

nome e/o id del processo
stato del processo (attesa, pronto, ecc.)
contesto h/w del processo (registri del
processore)
altre informazioni per la gestione del
processo (risorse possedute, informazioni per
la gestione della memoria, ecc.)

Quando un processo esce dallo stato di esecuzione le informazioni relative al suo contesto h/w)
vengono ricopiati nel suo PD, quanto ritorna nello stato di esecuzione, il contesto viene ricopiato
dal suo PD ai registri del processore.
I descrittori di processo inoltre contengono dei puntatori che consentono di inserire i processi nelle
varie code associate al funzionamento del sistema.
Scheduling dei processi
I processi possono essere catalogati come CPU-bound se fanno un uso intensivo della CPU e poche
operazioni di I/O, I/O bound se fanno molte operazioni di I/O ed utilizzano poco il processore.
Spesso i processi alternano comportamenti I/O-bound e CPU-bound.
Lo scheduling pu essere di tipo:
non-preemptive o cooperativo: il processo in esecuzione rilascia volontariamente il processore
(quando termina, o quando si blocca in attesa di I/O);
preemptive: il processo in esecuzione forzato a rilasciare il processore (e messo nella Ready
List) a vantaggio di un altro processo; cos si evita che un processo di tipo CPU-bound
monopolizzi il processore per tempi troppo lunghi.
Loverhead del SO la percentuale di tempo di CPU usato dal SO per svolgere le sue funzioni; un
overhead troppo alto vanifica uno degli obiettivi principali dei SO: lefficienza nelluso del
processore. Le operazioni di scheduling, a causa delle commutazioni di contesto, possono
comportare overhead eccessivi.
Le diverse politiche dello scheduler corrispondono a diversi obiettivi (indici di prestazione), spesso
contrastanti tra loro, ad esempio:
massima utilizzazione del processore;
massimo throughput (TH) = n. di processi/tempo;
minimo turnaround time (TT) = tempo totale per terminare un processo (tempi di attesa + t. di
esecuzione);

Scheduling FCFS - First Come, First Served
La Ready List (RL) una coda FIFO ed di tipo non preemptive, per cui favorisce i processi CPU-
bound e penalizza quelli brevi e I/O-bound, che (ad ogni richiesta di I/O il processo torna in fondo
alla RL).
una politica non buona per TH (throughput), TT (turnaround time), e TR (tempo di risposta): i
processi CPU-bound monopolizzano il processore e impediscono a quelli brevi di terminare
Mentre in esecuzione un processo CPU-bound, tutti quelli I/O-bound diventano pronti e partono
uno dopo laltro per una breve esecuzione per risospendersi in attesa di I/O; lI/O rallenta e il
processore pu trovarsi senza processi pronti (effetto convoglio).
Per contro una politica molto semplice da realizzare.
Scheduling RR - Round Robin
La Ready List (RL) una coda FIFO, come per FCFS, ma in pi viene introdotto un meccanismo di
timeslicing: allo scadere di un quanto temporale il processo in esecuzione (se non ha liberato il
processore prima) viene messo in fondo alla RL.
quindi uno scheduling di tipo preemptive, da realizzare, con overhead minimo, e fornisce un
trattamento abbastanza equo a tutti i processi.
Risultano buoni il TH (throughput) e il TR (tempo di risposta) se il quanto temporale non troppo
piccolo. Lefficienza dipende molto dalla scelta del quanto temporale: se troppo piccolo,
loverhead di commutazione di contesto diventa inaccettabile mentre se troppo grande, diventa
uguale alla politica FCFS.
PS - Priority Scheduling
La Ready List (RL) ordinata per priorit decrescente, oppure composta da N liste, una per
ciascun livello di priorit. Pu essere preemptive oppure non preemptive.
C il rischio di starvation: i processi a priorit bassa possono rimanere in attesa indefinita, se ci
sono sempre processi pi prioritari pronti; per eliminare questo rischio spesso adottata la tecnica
di aging, che consiste nellaumentare la priorit col tempo dattesa.
Loverhead pu essere alto.
Scheduling SPN - Shortest Process Next
uno scheduling di tipo non preempitive in cui la Ready List (RL) ordinata per tempo di
esecuzione crescente (equivale ad assegnare una priorit pari al reciproco del tempo di esecuzione).
Favorisce i processi brevi, penalizza quelli lunghi, che tendono a rimanere in fondo alla Ready List.
una politica buona per TH (throughput) e per il TR (tempo di risposta), perch i processi brevi
terminano presto. Non semplice da realizzare perch bisogna conoscere (o stimare) il tempo di
esecuzione dei processi. Loverhead pu essere alto (per gestire i tempi di esecuzione), e comporta
il rischio di starvation per i processi lunghi, che possono rimanere in attesa indefinita, se ci sono
sempre processi brevi che li sorpassano nella Ready List.
MF Multilevel Feedback Scheduling
la politica di scheduling pi generale: non potendo prevedere il futuro, ci si basa sul
comportamento passato dei processi. Ci sono pi ready list a propriet diverse, assegnate
dinamicamente. Per ciascuna lista si utilizza una politica RR. Le priorit sono divise in tre fasce:
processi real-time, processi interattivi e processi batch. Ogni volta che un processo interattivo
esaurisce tutto il suo quanto di tempo la sua priorit viene diminuita (fino a raggiungere il valore
minimo previsto per i processi interattivi), mentre ogni volta che effettua la transizione pronto-
attesa (e quindi non ha consumato lintero quanto di tempo) la sua priorit viene incrementata (fino
a raggiungere il valore massimo previsto per i processi interattivi).
In questo modo i processi CPU-bound, scendono via via di priorit mentre quelli I/O si portano a
priorit elevata.
Esiste il rischio di starvation, per prevenirlo si ricorre allaging, aumentando la priorit dei processi
con il tempo di attesa.
Scheduling in Linux
In Linux lo scheduling si basa sul concetto di timesharing, per cui ad ogni processo assegnato un
quanto di tempo massimo per l'esecuzione. La selezione del prossimo processo da eseguire basata
sul concetto di priorit, che pu essere dinamica o statica. In particolare, la prima introdotta per
evitare il fenomeno della starvation, mentre la seconda stata introdotta per consentire la gestione
di processi real-time. Ai processi real-time (pi precisamente soft real-time, utili ad esempio per
riprodurre flussi audio e/o video in applicazioni multimediali) assegnata una priorit maggiore di
quella assegnata ai processi ordinari.
Di norma Linux prevede uno scheduling con prelazione (preemptive), per cui ad un processo viene
tolta la CPU se esaurisce il quanto di tempo a sua disposizione o un processo a priorit pi alta
pronto per l'esecuzione (stato TASK RUNNING).
La durata del quanto di tempo tipicamente di 20 clock ticks, o 210 millisecondi, ma viene
modificato dinamicamente se ci si rende necessario.
Ci sono 3 diverse bande di priorit, un processo assume un valore iniziale in una di queste bande a
seconda della sua tipologia:
processi real time (massima priorit statica);
kernel (media priorit statica);
processi utente (bassa priorit dinamica).
Allinterno del codice del kernel sono inseriti di punti di preemption, le routine del kernel possono
subire preemption in punti sicuri (in cui le strutture di dati del kernel sono coerenti e, se in uso,
protette da semafori).
I processi real-time hanno la precedenza sul kernel e, se necessario, possono fruire della preemption
del kernel.
Le priorit dei processi utente sono calcolate ogni 1s, sulla base del comportamento precedente:
possono crescere (I/O bound) o decrescere (CPU bound) allinterno della propria banda.
Ogni processo ha associati una priorit base (iniziale), un modificatore impostabile (nice) e un
parametro legato al tempo (RCU = Recent CPU Usage). Ad ogni tick di sistema viene incrementato
lo RCU del processo in esecuzione.
Dopo ogni quanto il SO rischedula il processo in esecuzione e ricalcola la priorit di tutti i processi:
RCU = RCU/2
nuovaPriorit = base + nice + RCU/2
(N.B.: valori pi alti di priorit corrispondono a una priorit minore)
Solo il processo in esecuzione ha aumentato lo RCU durante il suo time-slice e quindi alla
rischedulazione gli altri processi pronti hanno maggior priorit.
I processi I/O bound ad ogni risveglio completano la chiamata a sistema alla priorit (kernel)
dellevento atteso, che sempre maggiore di quelle utente.
La priorit di un processo pu essere variata agendo sul nice, che pu variare da -20 a 19, valori
elevati di nice abbassano la priorit del processo, solo lamministratore pu diminuire il nice di un
processo.

Scheduling in Windows NT / W2K
Windows NT progettato per fornire tempi di risposta minimi in un ambiente interattivo
monoutente, oppure nel ruolo di server. Lo scheduling preemptive, basato su 32 livelli di priorit,
con scheduling RR in ciascun livello.
I 32 livelli di priorit sono ripartiti in 2 classi:
Real-time (alta priorit statica: livelli 31 - 16),
Variabile (bassa priorit dinamica: 15 - 0): pu variare tra il valore base e 15, crescendo quando
il thread non usa tutto il time slice e diminuendo quando il thread lo usa tutto.

Concorrenza e cooperazione tra processi
Nel mondo reale:
ognuno fa qualcosa concorrentemente ad altri;
pi individui collaborano per il raggiungimento di uno stesso obiettivo;
spesso occorre terminare una attivit prima di poterne intraprendere unaltra;
un lavoro complesso si conclude prima se pi soggetti collaborano fra loro;
le attivit sviluppate da pi persone sono per la maggior parte indipendenti e non
interferenti.
Quando pi persone devono cooperare per raggiungere un obiettivo, si devono:
pianificare le fasi intermedie di attivit,;
coordinare le attivit;
predisporre le risorse necessarie;
rendere possibile la realizzazione delle varie fasi;
evitare intasamenti o conflitti negli spazi comuni.
Per comprendere bene i problemi legati alla concorrenza e alla cooperazione tra i processi,
possiamo trasportare questi concetti al sistema di elaborazione:

In un sistema di elaborazione abbiamo un insieme di processi interagenti che svolgono attivit
parzialmente contemporanee. Linterazione si manifesta in due forme:
COOPERAZIONE: che consente di diminuire il tempo di esecuzione e permette un elevato
sfruttamento delle risorse;
COMPETIZIONE: pi processi richiedono la stessa risorsa.
Grafi delle precedenze
Per alcuni problemi pi complessi possibile scomporre un processo in sottoprocessi, il grafo delle
precedenze uno strumento che consente di verificare se possibile una esecuzione parallela dei
sottoprocessi individuati.
Esempio
f = (a + b)*(c + d) + e
Di seguito rappresentata una rappresentazione sequenziale del
calcolo.

Il calcolo per pu anche essere eseguito in modo non sequenziale,
come evidenziato dal seguente grafo delle precedenze.

Esempio
Si devono preparare (P
i
) e stampare (S
i
) 3 documenti. Ci sono
diverse possibilit se si lavora sequenzialmente:

Ecco il diagramma delle precedenze, che evidenzia il grado di
parallelismo del sistema.

Mutua esclusione
Il problema della mutua (in senso di reciproca) esclusione si ha quando due o pi processi si
contendono luso di una risorsa non condivisibile e non prerilasciabile.
Chiamiamo sezione critica del processo la sequenza di istruzioni che richiedono il possesso in
mutua esclusione della risorsa.
Affinch il sistema si comporti correttamente, necessario che le sezioni critiche dei diversi
processi non si sovrappongano nel tempo.

Uso corretto
della risorsa
mutex da parte
di P1 e P2

Uso non cor-
retto della ri-
sorsa mutex da
parte di P1 e
P2

Possiamo immaginare che il codice del processo abbia una struttura del tipo:
. . . .
/*appropriati della risorsa R*/
/*sezione critica (uso di R) */
/* rilascia R*/
. . . .
Una prima soluzione possibile sembra essere questa:
. . . .
/*appropriati della risorsa R: aspetta che R sia libera, poi la
occupala */
while(semR == 0);
semR = 0;
/* rilascia R*/
semR = 1;
. . . .
che utilizza una variabile condivisa semR (inizializzata a 1) con il significato 1 = risorsa libera, 0 =
risorsa occupata.
Questa soluzione, semplice e apparentemente efficace, in realt NON corretta. Infatti si pu
verificare che in presenza di un intervento dello scheduler dopo la lettura della variabile semR e
prima della sua modifica, possibile che due processi concorrenti si trovino entrambi
contemporaneamente nella propria sezione critica.
La soluzione rendere indivisibili le istruzioni di lettura e modifica della variabile semR.
Ipotizziamo che il SO renda disponibili per questo scopo la primitiva (indivisibile)
int testAndClear(int var)
che porta a 0 var, ma restituisce il valore di var prima della modifica.
Il nuovo codice diventa
. . . .
/*appropriati della risorsa R: aspetta che R sia libera, poi
occupala*/
while(testAndClear(semR) == 0);
/* rilascia R*/
semR = 1;
. . . .
In questo modo abbiamo utilizzato la variabile semR come un semaforo a basso livello, che
effettivamente risolve il problema della mutua esclusione.
La soluzione per non efficiente per due motivi:
Si verifica una forma di attesa chiamata busy waiting, i processi rimangono nello stato di
esecuzione, continuando a testare la variabile semaforo, e poi commutano a pronto, ma in realt
sono in attesa della risorsa e quindi dovrebbero, pi correttamente, portarsi nello stato di attesa;
In caso di pi precessi in competizione, non c alcuna garanzia che la risorsa vada al primo
processo che si bloccato ad aspettarla.
La soluzione pi efficiente utilizza i semafori ad alto livello o semafori di Dijkstra.
Un semaforo di Dijkstra costituito da una variabile intera non negativa e da una coda di processi.
Oltre allinizializzazione del valore della variabile, sul semaforo sono definite due primitive:
wait(S) se possibile decrementa il valore della variabile associata al semaforo, altrimenti porta il
processo nello stato di attesa, nella coda associata al semaforo;
signal(S): se la coda associata al semaforo non vuota, porta nello stato di pronto il primo
processo della coda, altrimenti incrementa la variabile associata al semaforo.
I semafori e le primitive wait e signal devono essere fornite dal nucleo del SO, perch richiedono
lintervento del dispatcher.
Utilizzando il semaforo di Dijkstra semR inizializzato a 1, il codice diventa
. . . .
/*appropriati della risorsa R: aspetta che R sia libera, poi
occupala */
wait(semR);
/* rilascia R*/
signal(semR);
. . . .
In questo modo, oltre a risolvere il problema dellaccesso in mutua esclusione, evitiamo il busy
waiting e garantiamo che il primo processo che si mette in coda per usare la risorsa R sar il primo
ad ottenerla nel momento in cui verr rilasciata.
Stallo
Una risorsa una qualunque entit necessaria ad un processo per sviluppare la propria attivit.
Come il processo, anche la risorsa una astrazione. Lindisponibilit di una risorsa (ad esempio
perch in dotazione ad un altro processo) comporta il blocco dellevoluzione del processo che la
richiede. Le risorse possono essere:
equivalenti o non equivalenti;
riutilizzabili o non riutilizzabili (ad es. un buffer condiviso fra produttore e consumatore
riutilizzabile; un dato estratto dal consumatore non lo );
condivisibili (possono essere usate da pi di un processo contemporaneamente, es. il disco
magnetico) o non condivisibili (occorre attendere che un processo ne abbia terminato lutilizzo
prima che un altro processo possa ottenerne il possesso, ad esempio il processore).
prerilasciabili (si possono sottrarre ai processi che ne stanno usufruendo, es. il processore) o
non prerilasciabili (ad es., una stampante utilizzata in modo interattivo).
Un sistema di processi si dice in stallo o blocco critico (o deadlock, in inglese) se non pu
raggiungere il suo stato finale in quanto i processi si bloccano a vicenda contendendosi luso di
alcune risorse.
Le condizioni per il verificarsi dello stallo sono:
Mutua esclusione: le risorse coinvolte non sono condivisibili n prerilasciabile;
Allocazione parziale: un processo non richiede tutte le risorse necessarie in un'unica volta, ma
in diversi momenti della sua evoluzione, mano a mano che gli si rendono necessarie;
Attesa circolare: i processi sono in attesa di risorse occupate da altri processi a loro volta in
attesa di risorse occupate dai primi.
La situazione di attesa circolare pu essere evidenziata dal grafo di allocazione delle risorse, un
grafo in cui i nodi circolari rappresentano i processi, i nodi triangolari rappresentano le risorse, un
arco orientato dalla risorsa R al processo P rappresenta il possesso da parte di P della risorsa R, un
arco orientato da un processo P a una risorsa R rappresenta lattesa di R da parte di P.

Una volta che lo stallo si verificato, lunica soluzione possibile la distruzione dei processi
bloccati e di tutti quelli che da questi dipendono.
Per prevenire lo stallo si deve agire sulla politica si allocazione delle risorse, eliminando almeno
una delle condizioni necessarie per lo stallo.
I principali metodi di prevenzione dello stallo sono:
Preallocazione statica delle risorse: i processi devono chiedere tutte le risorse prima di iniziare,
rimangono nello stato di nuovo finch non ottengono tutte le risorse, e le manterranno per
tutta la loro durata. evidente che questa tecnica porta a uno spreco nellutilizzo delle risorse.
Preallocazione dinamica delle risorse: i processi chiedono le risorse tutte assieme, per durante
la loro evoluzione, nel momento in cui se ne rende necessaria una.
Allocazione gerarchica delle risorse: viene stabilito un ordinamento nelle risorse, un processo
che sta usando risorse, ne pu ottenere altre solo di ordine pi elevato. Per ottenere risorse di
R1
R2
R3
P1
P2
P3
ordine pi basso, deve prima rilasciare quelle di ordine maggiore, richiedere la risorsa di ordine
inferiore, richiedere di nuovo quelle superiori.
I primi due metodi eliminano la condizione di allocazione parziale, lultimo, pi efficiente, elimina
la possibilit che si verifichi unattesa circolare.
Un altro metodo, utilizzabile quando si deve gestire un insieme di risorse equivalenti tra loro,
chiamato algoritmo del banchiere.
Questo algoritmo applicabile se si conosce il numero massimo di risorse richieste da un processo
per terminare le sue attivit (fido), ogni processo di impegna, una volta ottenuto un numero di
risorse pari al fido, a terminare e a restituire tutte le risorse ottenute.
A ogni richiesta lecita da parte dei processi, il banchiere conceder il prestito se vede che una volta
soddisfatta la richiesta, gli rimangono in cassa abbastanza risorse da terminare almeno un processo.
Gestore della memoria
Il problema della rilocazione
Il programmatore non sa dove il programma sar caricato in memoria quando verr eseguito, la
posizione infatti dipender da quali e quanti moduli compongono il programma e da quali e quanti
altri programmi saranno presenti in memoria nel momento in cui esso verr caricato.
Gli indirizzi di memoria contenuti nel codice e nei dati di un programma sono indirizzi logici
(effettuati per mezzo di nomi simbolici), diversi da quelli fisici. Un traduttore (compilatore o
assemblatore) produce del codice in formato binario, in cui gli indirizzi sono pure rappresentati da
numeri binari. In generale questi indirizzi non coincidono con indirizzi fisici, solitamente sono
indirizzi relativi (offset) a un indirizzo base che quello iniziale del programma. Per poter eseguire
il programma questi indirizzi relativi dovranno essere tradotti nei corrispondenti indirizzi fisici,
sommando a ciascuno un valore costante che rappresenta la posizione iniziale di caricamento del
programma stesso.
Questa operazione prende il nome di rilocazione e pu avvenire in diversi momenti ed essere
effettuato da diversi componenti del sistema di elaborazione.
Rilocazione assoluta.
La situazione pi semplice e meno elastica quella in cui la rilocazione viene effettuata
direttamente dal programma traduttore (assemmblatore o compilatore), di solito utilizzando
direttive fornite dal programmatore circa lindirizzo iniziale del programma. In tal caso il traduttore
produce codice binario assoluto e il programma pu essere caricato solo nella zona di memoria
imposta dai suoi indirizzi.
Rilocazione statica
La rilocazione viene effettuata dal loader nel momento in cui carica il programma in memoria
centrale. Per far questo utilizza una tabella, lasciata dal linker allinterno del programma, che
contiene gli indirizzi di tutte le istruzioni da rilocare. Questa operazione pu essere fatta una sola
volta, quindi una volta collocato in memoria il programma questo non potr pi essere spostato.
Rilocazione dinamica
Con questa tecnica, che richiede un opportuno supporto da parte dellhardware, il programma viene
caricato in memoria senza rilocazione, il calcolo degli indirizzi effettivi di memoria viene effettuato
run time.
f(a) = B + a dove B lindirizzo di base e a lindirizzo logico allinterno del programma.


Funzioni del gestore della memoria
La gestione della memoria (effettuata dal SO usando gli accorgimenti presenti nellhardware),
consiste nel suddividere la memoria per consentire la presenza di pi processi (presupposto
indispensabile per il multitasking), cercando di per farci stare il numero maggiore possibile di
processi (quanto maggiore questo numero, tanto minore la probabilit che la ready list sia
vuota).
La gestione della memoria deve garantire:
Protezione: necessario impedire che un processo acceda a locazioni di memoria di un altro
processo (o del SO). La verifica non pu essere fatta dal compilatore perch molti indirizzi
vengono calcolati al momento della esecuzione (ad es. i metodi di indirizzamento per accedere
agli elementi di un vettore) e i processi possono essere rilocati da una posizione di memoria ad
unaltra. La verifica quindi va fatta al momento della esecuzione, utilizzando funzionalit che
devono essere messe a disposizione dellhardware.
Trasparenza: loperazione di allocazione deve essere invisibile al processo, in particolare il
programmatore deve poter scrivere il codice senza preoccuparsi di come il programma verr
caricato in memoria.
Allocazione logica: le sezioni di memoria (codice e dati) assegnate a un programma devono
essere viste da questultimo come fisicamente contigue, anche qualora fossero poste in aree
disgiunte di memoria.
Condivisione: necessaria per consentire la condivisione di dati e di codice. La condivisione di
dati necessaria nel caso di processi cooperanti che fanno parte del medesimo programma ed
hanno bisogno di dati comuni. La condivisione di codice quando un insieme di subroutine deve
essere utilizzato da pi processi. In questo caso infatti conviene che di esse vi sia in memoria
ununica copia accessibile a tutti, piuttosto che averne tante copie replicate per ciascun
processo. Questo tipo di condivisione possibile solo se il codice delle subroutine rientrante,
cio se tutte le variabili da esse utilizzate sono memorizzate nello stack.
Organizzazione logica
I programmi sono costituiti da moduli, che vengono scritti e compilati separatamente. Il modo pi
naturale di vedere la memoria per il programmatore non uno spazio di indirizzi lineare (da 0 fino
allindirizzo massimo), ma costituito da spazi di indirizzi separati (uno per ciascun modulo).
Se il SO e lhardware consentono di gestire in forma di moduli i programmi e i dati, diventa facile
associare ai diversi moduli diversi livelli di protezione (read-only, execute-only) e organizzare la
condivisione di moduli.
Allocazione a partizionamento statico
La memoria viene divisa in partizioni di dimensioni fisse (uguali oppure diverse). Le dimensioni
delle partizioni non possono essere modificate. un metodo facile da realizzare, ma il grado di
multiprogrammazione limitato (un processo per partizione) Se non ci sono partizioni libere, il SO
pu liberarne una trasferendo su memoria secondaria (swap) il processo relativo, oppure mantenere
i nuovi processi nello stato di disponibilit fino a quando non si libera una partizione di memoria
sufficiente a contenerli.
Partizioni fisse di dimensioni uguali

Un processo di dimensione inferiore o uguale a quella delle partizioni pu essere caricato in una
qualsiasi partizione libera. Se un processo pi grande di una partizione, il programma deve essere
progettato con la tecnica di overlay. Anche i processi piccoli occupano una intera partizione: ci
provoca un uso inefficiente della memoria indicato come frammentazione interna.
Partizioni fisse di dimensioni diverse

Ogni processo pu essere collocato nella partizione pi piccola in grado di contenerlo. Rispetto al
caso precedente riduce la frammentazione interna (memoria inutilizzata allinterno di ciascuna
partizione). Le partizioni piccole riducono lo spreco per processi piccoli, le partizioni grandi
riducono la necessit di overlay.
Per utilizzare questa tecnica il SO dovr avere una tabella che descrive le partizioni (posizione
iniziale, dimensione e stato).
Allocazione a partizionamento dinamico
Il numero e le dimensioni delle partizioni sono variabili, a ciascun processo viene assegnata una
partizione delle dimensioni richieste (nessuna frammentazione interna).
Col passare del tempo si formano in memoria delle aree di dimensioni piccole non utilizzabili
(frammentazione esterna). Per recuperare queste aree non utilizzabili necessario spostare i
processi in memoria e compattare le aree libere in ununica area pi grande e quindi utilizzabile
(partizionamento dinamico rilocabile, possibile solo se lh/w supporta la rilocabilit dei
programmi).
Loperazione di compattazione richiede tempo di CPU.

Memoria virtuale paginata
la tecnica utilizzata dai SO moderni. Ogni processo lavora in un proprio spazio di memoria
virtuale, le cui dimensioni possono essere superiori alla dimensione della memoria fisica,
completamente inaccessibile agli altri processi; anche il Sistema Operativo lavora in un proprio
spazio di memoria virtuale.
La memoria fisica viene divisa in blocchi uguali, detti frame (o pagine fisiche), di dimensioni
spesso piccole (es: 4KB) e uguali alla dimensione di un blocco del disco.
Anche lo spazio di memoria indirizzato da ciascun processo (memoria virtuale) diviso in blocchi
delle medesime dimensioni, detti pagine (o pagine logiche o pagine virtuali), nella memoria fisica
sono mappate solo alcune delle pagine di memoria virtuale di ciascun processo (resident set del
processo stesso), le altre rimangono nella memoria secondaria e vengono prelevate quando
necessario.
In questo modo il numero di processi presenti in memoria maggiore perch mappando in memoria
centrale solo una piccola parte del codice e dei dati di ciascun processo quindi rimane pi memoria
libera per altri processi con un maggior rendimento nelluso del processore (pi processi sono in
memoria, meno probabile che la ready list rimanga vuota).
Inoltre ogni processo pu indirizzare pi memoria di quella fisica disponibile senza la necessit di
utilizzare tecniche di overlay.
I processi generano indirizzi di memoria virtuale, che devono essere tradotti nei corrispondenti
indirizzi di memoria fisica (mappatura della memoria virtuale nella memoria fisica). Per far questo
un indirizzo di memoria virtuale un processo considerato diviso in due parti: un indice di pagina e
un offset nella pagina.
Anche gli un indirizzo fisico costituito da due parti, numero di pagina fisica e offset allinterno
della pagina. I frame occupati da un processo possono non essere contigui, la traduzione da
indirizzo virtuale a indirizzo fisico avviene trovando il numero di pagina fisica su cui mappata la
pagina di memoria virtuale alla quale si deve accedere.
Lhardware che realizza questa traduzione si chiama MMU (Mapping and Management Unit).

Per ciascun processo il SO mantiene una tabella delle pagine. Questa tabella ha tante righe quante
sono le pagine di memoria virtuale del processo; elemento di indice i corrisponde alla i-esima
pagina dello spazio di memoria virtuale del processo e contiene:
lindice del frame nella memoria fisica in cui collocata la i-esima pagina del processo;
la posizione della pagina nella memoria di massa;
alcuni bit di controllo:
o P = pagina presente nella memoria fisica,
o M = pagina modificata durante la permanenza in memoria fisica (se non stata
modificata non occorre ricopiarla su disco in caso di rimpiazzo),
o bit di protezione (sola lettura, sola esecuzione, accesso riservato al SO, ).
Ad esempio, si consideri il caso di un processore che genera
indirizzi logici da n = 32 bit (pu indirizzare 4 Gbyte di memoria
virtuale) con una memoria fisica da 16 Mbyte (indirizzi fisici da
m = 24 bit).
Suddividendo lo spazio degli indirizzi logici in pagine da 64
Kbyte:
il numero di pagine logiche 4G/64K = 64K,
lindice di pagina logica di 16 bit (q =16),
64 Kbyte corrispondono ad un offset di 16 bit,
la memoria fisica risulta comprendere 16M/64K = 256 pagine,
lindice di pagina fisica di 8 bit (l =8),
la page table ha 64K righe da 8 bit.

Le page table associate ai diversi processi hanno dimensioni diverse (dipendono dalla dimensione
del processo), alcuni processi sono molto grandi e, di conseguenza hanno page table con molti
elementi. La page table va collocata in memoria e un apposito registro h/w (page table pointer)
punta alla page table attiva.
Se la dimensione della memoria virtuale molto grande, la dimensione della page table pu
diventare problematica, in questo caso si ricorre a una organizzazione della page table su pi livelli.
Ad es. con 32 bit si indirizza uno spazio virtuale di 4GB,
nellipotesi di pagine da 4KB (offset di 12 bit), il numero di
pagine virtuali 2
20
= 1M.
Una page table con 1M elementi, ciascuno da 4 byte, occupa 4MB,
cio 2
10
pagine(per un solo processo!)
Scomponendo la tabella in due livelli, si usa una root page table
(di primo livello) da 4KB per paginare la page table (di secondo
livello) del processo, in questo modo sufficiente che siano
caricate in memoria la root page table del processo in esecuzione
e la parte della page table che referenzia le pagine attualmente
necessarie.

I sistemi di memoria virtuale funzionano in modo efficiente in virt del principio di localit
verificato empiricamente, infatti in ogni breve intervallo di tempo, gli indirizzi di memoria richiesti
da un processo tendono ad essere localizzati nelle medesime aree e ci consente di fare previsioni
abbastanza affidabili su quali pagine del processo serviranno nel futuro immediato). Una volta che
una pagina virtuale stata portata in memoria fisica, il processo continuer ad utilizzarlo per un po
di tempo.
Quando un processo tenta di accedere a una pagina di memoria virtuale non presente nella memoria
fisica si genera una eccezione h/w denominata page fault, che viene gestita dal Sistema Operativo.
evidente che perch la visualizzazione della memoria risulti efficiente necessario che il numero
complessivo dei page fault risulti ridotto rispetto al numero di accessi totali in memoria.
Ad esempio, se il tempo di accesso alla memoria centrale
tA=60ns, la probabilit di page fault pF=0,1% (un page fault ogni
1000 accessi) e il tempo necessario a gestire un page fault
tF=20ms, il tempo medio di accesso alla memoria risulta essere:
tM = (1 - pF)*tA + pF*tF 20 060 ns
cio l'elaboratore rallenta pi di 300 volte (tM / tA = 20'060/60
300). Per contenere il rallentamento sotto il 10%, bisognerebbe
avere N > 3'300'000 (un page fault ogni 3'300'000 accessi).

Per ridurre il numero di page fault molto importante che il SO sia progettato in modo da evitare il
trashing, che si verifica quando il SO decide di sostituire (swap-out) una pagina poco prima che il
processo cerchi di accedervi. In questo caso la pagina appena sostituita va riportata subito in
memoria (swap-in) con il conseguente swap-out di un altro blocco. Se questo succede troppo
frequentemente il processore passa gran parte del suo tempo ad eseguire swap, invece che ad
eseguire le istruzioni dei processi.
Un sistema con memoria virtuale richiede che il SO intervenga per attuare delle scelte, basate su
opportune politiche (efficienza/overhead):
politica di fetch (prelievo): quando trasferire una pagina da disco a memoria?
demand paging: la pagina viene portata in memoria solo quando il processore chiede di
accedere ad un suo indirizzo, provoca molti page fault allavvio di ogni processo;
prepaging: oltre alla pagina richiesta, si portano in memoria anche le pagine che risiedono
su settori adiacenti del disco. pi efficiente trasferire da disco pi settori/pagine
consecutivi piuttosto che un settore alla volta (per via dei tempi di seek e di rotazione), ma
c il rischio di portare in memoria pagine che non servono.
politica di replacement (sostituzione): quale pagina rimuovere per far posto alla pagina da
trasferire? La pagina che viene rimossa dovrebbe essere quella con la minor probabilit di essere
richiesta nellimmediato futuro; il comportamento nellimmediato futuro viene predetto sulla
base di quello del passato recente. Alcune pagine (critiche) devono rimanere sempre in memoria
e i frame che le contengono non devono subire il rimpiazzo (frame locking); si tratta dei frame
contenenti: il kernel e le routine di servizio delle interruzioni, processi con esigenze real-time,
strutture di dati del SO (liste di descrittori di processi) e simili. Il frame locking si ottiene
settando un bit di controllo (bit di lock) associato al frame o nella page table.
Vediamo i principali algoritmi di sostituzione delle pagine:
Algoritmo ottimo: la pagina selezionata per il rimpiazzo quella cui il processore in futuro
chieder di accedere pi tardi di tutte. Si tratta di un algoritmo impossibile da realizzare
(servirebbe la sfera di cristallo) ma serve come elemento di confronto per gli altri metodi.
Algoritmo Least Recently Used (LRU): la pagina selezionata per il rimpiazzo quella che
da pi tempo non subisce accessi. Lefficienza prossima a quella dellalgoritmo ottimo, ma
complicato da realizzare (si deve tener traccia del tempo di ultimo accesso di ogni pagina)
e comporta un grande overhead.
Algoritmo First In, First Out (FIFO): la pagina selezionata per il rimpiazzo quella
presente in memoria da pi tempo. semplice da realizzare, con poco overhead, ma poco
efficiente (assume che la pagina pi vecchia non venga pi usata: spesso non vero).
Algoritmo Tipo clock: ha lefficienza di LRU con loverhead del FIFO. A ciascun frame
associato uno use bit, che indica se la pagina stata usata. Lo use viene bit posto a 1 quando
la pagina viene caricata in memoria e quando la pagina subisce un accesso (viene usata).
Quando deve rimpiazzare una pagina, il SO esamina, ad uno ad uno, gli use bit dei frame
candidati al rimpiazzo, considerati come elementi di un buffer circolare. Se lo use bit vale 1,
lo azzera e prosegue lesame. Quando incontra il primo frame con use bit = 0, seleziona quel
frame per il rimpiazzo e termina lalgoritmo. Al prossimo rimpiazzo lesame riparte dal
frame successivo a quello appena rimpiazzato. Gli use bit con il valore 0 indicano pagine
che non sono state pi usate almeno dallultimo azzeramento. Il nome (clock) deriva dallo
schema grafico dellalgoritmo.

Esiste una variante di questo algoritmo che preferisce rimpiazzare pagine che non sono state
modificate, e che quindi non devono essere riscritte su disco prima del rimpiazzo. Oltre allo
use bit, si tiene conto anche del modified bit, che indica se la pagina stata modificata (per
scrittura) durante la permanenza in memoria. Quando deve rimpiazzare una pagina, il SO
prima cerca nel buffer un frame con use=0, mod=0 (senza azzerare gli use bit uguali a 1 che
incontra), se completa un intero giro senza averne trovato uno riscandisce il buffer cercando
un frame con use=0, mod=1, questa volta azzerando tutti gli use bit=1 che incontra, se al
termine del secondo giro non ne ha trovato ancora nessuno, ne inizia un altro: questa volta la
ricerca avr di sicuro successo (gli use bit sono stati appena azzerati).
Page buffering: una variante dellalgoritmo FIFO, semplice da realizzare e con poco
overhead, che aumenta lefficienza (scarsa nel FIFO). Il SO cerca di mantenere sempre
un piccolo numero di pagine libere, le pagine rimosse vengono in realt accodate in 2
liste globali (che costituiscono un page buffer): se non sono state modificate, nella linked
list delle pagine libere (free page list), mentre se sono state modificate, vengono inserite
in unaltra linked list (modified page list). Queste due liste fungono da cache tra
memoria e disco: se il processo accede di nuovo a una di queste pagine rimosse, essa pu
essere ripristinata e reinserita nella page table Quando una nuova pagina caricata in
memoria, i frame da sovrascrivere vengono estratti, con modalit FIFO, dalla free page
list (se ce ne sono). Se la free page list vuota, le pagine della modified page list
vengono tutte ricopiate su disco (pi efficiente che ricopiarle una alla volta) e inserite
nella free page list (in alternativa possono venir ricopiate su disco, in blocco, quando il
sistema libero). La gestione delle pagine dalle liste ha luogo senza spostare le pagine
fisicamente e sacrificando alcune pagine (che fungono da buffer), si ottiene una
efficienza ottima, con un semplice algoritmo (FIFO)
politica di gestione del resident set: quante pagine di un processo tenere in memoria? La
gestione del resident set comprende le scelte che riguardano: la dimensione delle pagine, la
dimensione del resident set (numero di frame allocati a ciascun processo) e lambito in cui
effettuare la scelta del frame da rimpiazzare (replacement scope).
Dimensioni delle pagine. Se le pagine sono troppo piccole diventa elevato il numero di
pagine di ciascun processo e di conseguenza la dimensione delle page table, aumenta quindi
la porzione di page table non mappata in memoria fisica e la probabilit di page fault doppi
(su page table e sulla pagina dati). Se le pagine sono troppo grandi aumenta la
frammentazione interna e diminuisce il numero di pagine di ciascun processo in memoria
fisica, aumentando la probabilit di page fault. Esistono processori in grado di gestire pagine
di dimensioni variabili, grandi per il codice dei processi e piccole per gli stack dei thread. La
gestione di pagine di dimensioni differenti per complicata e la gran parte dei SO prevede
pagine di dimensioni uguali.
Dimensione del resident set: la scelta tra allocazione fissa, cio a ciascun processo
assegnato un numero fisso di frame per cui in seguito ad un page fault, viene rimpiazzata
una pagina dello stesso processo, e allocazione variabile, in cui il numero di frame assegnati
a ciascun processo varia. In questo caso il SO deve valutare il comportamento dei processi
per decidere se aumentare o diminuire il numero di frame ad essi assegnati.
Dominio di rimpiazzo (replacement scope): condiziona la scelta di quale pagina rimuovere
per caricarne unaltra. Pu essere locale (local scope) o globale (global scope). Con il
dominio locale, quando si verifica un page fault, la pagina rimpiazzata dello stesso
processo. Con il dominio globale invece quando si verifica un page fault, la pagina da
rimpiazzare pu essere scelta tra tutte le pagine presenti in memoria (che non siano bloccate
dal bit di lock). Con la allocazioni fissa, il dominio di rimpiazzo pu essere solo locale, con
la allocazioni globale, il dominio di rimpiazzo pu essere locale oppure globale. In generale
le politiche globali tendono a favorire i processi CPU bound, che utilizzando molto il
processore fanno anche accessi pi frequenti alla memoria.
o Allocazione fissa, scope locale: quando si verifica un page fault, la pagina
rimpiazzata dello stesso processo. A ciascun processo assegnato un numero fisso
di frame, se tale numero troppo piccolo, pu portare al trashing, se troppo grande,
si ha uno spreco della memoria perch si riduce il numero di processi presenti in
memoria e aumenta la probabilit che la ready list si svuoti.
o Allocazione variabile, scope globale. il metodo pi semplice e anche il pi usato
(in molti SO): il SO mantiene una lista di free frame (free list), al verificarsi di un
page fault un frame viene tolto dalla free list e aggiunto al resident set del processo,
se la free list vuota, il frame pu essere tolto ad un altro processo usando una delle
politiche di rimpiazzo (LRU, clock, ).
o Allocazione variabile, scope locale. Quando un processo viene caricato in memoria,
il SO gli assegna un certo numero di frame (usando criteri quali il tipo di
applicazione, i frame disponibili, ecc.); le pagine possono essere assegnate con
politica demand paging o prepaging. Al verificarsi di un page fault, la pagina da
rimpiazzare viene scelta tra quelle del processo stesso. Periodicamente il SO rivaluta
il numero di frame assegnati al processo, usando criteri intesi a migliorare
lefficienza, tra cui la strategia del working set. Il Working Set (WS) di un
processo linsieme di pagine usate effettivamente dal processo, costituito dalle W
pagine usate nelle ultime unit di tempo in cui il processo stato in esecuzione. Si
tratta di fare in modo che il Resident Set di un processo (le sue pagine presenti in
memoria) coincida con il suo Working Set. Il SO periodicamente rimuove le pagine
che non sono pi nel working set e il processo pu andare in esecuzione solo se tutto
il suo WS in memoria. Un metodo pi semplice utilizza la Page-Fault Frequency:
anzich valutare gli istanti in cui avvengono gli accessi alle pagine, si valuta la
frequenza con cui avvengono i page fault. Al verificarsi di un page fault, si valuta il
tempo trascorso dal page fault precedente, se toppo piccolo si aggiunge un frame al
WS, se troppo grande si rimuove un frame con use bit=0
politica di cleaning (sgombero): quando ricopiare da memoria a disco una pagina modificata?
Utilizzando la tecnica demand cleaning la pagina viene ricopiata su disco quando viene
selezionata per essere rimpiazzata da unaltra, in questo caso il processo che ha subito il page
fault deve attendere un tempo pi lungo (2 accessi al disco) prima di ripartire. Lalternativa il
precleaning:, ciola riscrittura su disco delle pagine modificate viene fatta ogni tanto, per
gruppi di pagine. Se tale riscrittura avviene troppo presto, la pagina pu venir modificata altre
volte (e laccesso al disco per la riscrittura diventare inutile). Il precleaning funziona bene
associato allalgoritmo di page buffering, pagine della modified list ogni tanto vengono riscritte
su disco (a gruppi) e inserite nella free list; da qui o ritornano nel resident set (se riusate),
oppure vengono rimpiazzate.
politica di load control (controllo del carico di lavoro): conviene avere in memoria pochi
processi con tante pagine ciascuno o tanti processi con poche pagine? Controlla il livello di
multiprogrammazione, se i processi sono troppo pochi, aumenta il rischio di ready list vuota, se
sono troppi, le dimensioni dei resident set potrebbero diventare insufficienti e provocare il
trashing. Se necessario ridurre il livello di multiprogrammazione, va individuato il processo da
sospendere (swap-out di tutte le sue pagine). La scelta di tale processo pu essere fatta con
diversi criteri:
il processo di priorit pi bassa (coinvolge lo scheduler);
il processo che provoca il maggior numero di page fault: probabilmente il suo WS non
residente e si bloccherebbe presto;
il processo con il resident set pi piccolo, perch il successivo lavoro per ripristinarlo il
minimo;
il processo con il resident set pi grande, perch il numero di frame resi liberi il massimo;
il processo con il massimo tempo di esecuzione rimanente, per far terminare prima gli altri
(che libereranno presto i relativi frame).
Gestione della memoria nei sistemi Linux
La memoria virtuale di Linux stata progettata per processori a 64 bit, per cui anche il paging a due
livelli comporta page table eccessive e utilizza un sistema di paging a 3 livelli.
Ogni processo ha:
una Page Directory che occupa una sola pagina e ciascun suo elemento punta a una pagina della
Page Middle Directory;
una Page Middle Directory che pu occupare pi pagine (una sola nei processori a 32 bit,
ciascun suo elemento punta a una pagina della Page Table;
una Page Table: ciascun suo elemento punta a un frame del processo.
Poich il kernel utilizza piccoli blocchi di memoria, luso del sistema di paging per il kernel stesso
sarebbe inefficiente. usato invece un sistema di allocazione dinamica di blocchi di dimensioni
variabili, noto come slab allocator.
Per le pagine dei processi usato un algoritmo di rimpiazzo di tipo clock in cui al posto dello use
bit c una age variable da 8 bit. Lage viene incrementata quando la pagina subisce un accesso e
decrementata periodicamente; quando age=0, la pagina vecchia (non usata da un po di tempo), e
quindi candidata al rimpiazzo. Lalgoritmo produce effetti simili allalgoritmo LRU.

Win NT - Gestione della memoria
Gli indirizzi virtuali da 32 bit, lo spazio virtuale da 4GB diviso in 2GB per il SO, 2GB per
lutente:
da 00000000 a 0000FFFF: indirizzi riservati (64 KB), usati per catturare gli usi di puntatori
nulli;
da 00010000 a 7FFEFFFF: spazio di indirizzi per lutente (da 2 GB) diviso in pagine virtuali
che possono venir caricate nei frame di memoria;
da 7FFFEFFF a 7FFFFFFF: indirizzi riservati (64 KB) usati per catturare gli usi di puntatori
fuori range;
da 80000000 a FFFFFFFF: spazio di indirizzi per il SO (da 2 GB) usato per il Microkernel,
lExecutive e i driver dei dispositivi di I/O.
Una pagina virtuale pu trovarsi in uno dei seguenti stati:
disponibile (la pagina al momento non usata)
riservata (la pagina destinata ad un processo, ma non ancora in uso), quando servir, la
pagina riservata pu essere allocata al processo rapidamente
assegnata (committed): (la pagina stata assegnata ad un processo ed in uso), la politica di
fetch usata di tipo demand paging a cluster per cui non viene portata in memoria solo la pagina
che ha provocato il fault, ma anche quelle ad essa contigue.
Per la gestione del resident set viene usata una allocazione variabile, con scope locale. Al verificarsi
di un page fault, la pagina da rimpiazzare viene scelta tra quelle del medesimo processo. Se c
disponibilit di memoria, il resident set di un processo viene lasciato crescere fino ad un WS
massimo, se la memoria scarsa, vengono rimosse dal resident set le pagine usate meno
recentemente (fino a WS minimo).

Gestore delle Periferiche

Un sistema di elaborazione ha periferiche per diversi impieghi:
per comunicare con luomo (tastiera, schermo, stampante, ...)
per memoria di supporto (dischi, nastri, ...)
per comunicare con altri calcolatori (modem, reti, ...).
I dispositivi periferici differiscono moltissimo tra loro, sia per quanto riguarda le velocit di
trasferimento (tastiera: 80 b/s, CD-ROM 6 Mb/s, video display 1Gb/s) che per la complessit del
controllo (tastiera pi semplice del disco), il tipo di dati trasferiti (caratteri, blocchi, ), la
rappresentazione dei dati (codifica, parit, ) ed altro.
Le diverse modalit di gestione dellI/O sono:
I/O programmato: il processore attende in busy waiting che il dato sia stato trasferito;
I/O gestito ad interrupt: il processore comanda una operazione di I/O e poi prosegue ad
eseguire un altro processo o thread, il dispositivo interrompe il processore quando il dato
stato trasferito;
Direct Memory Access (DMA): il processore comanda il trasferimento di un blocco di dati,
il dispositivo trasferisce i dati (cycle stealing), il dispositivo interrompe il processore quando
tutti i dati sono stati trasferiti.
Nel gestire le operazioni di I/O il SO intende garantire:
efficienza: le operazioni di I/O sono lente (perch lo sono i dispositivi) e il processore non
deve perdere tempo per esse. La gestione centralizzata di tutto lI/O da parte del SO (ad
interrupt o via DMA) il presupposto per il multitasking Infatti consente di usare in modo
efficiente la CPU, mandando in esecuzione un altro processo quando un altro richiede una
operazione di I/O). Nei sistemi con memoria virtuale paginata, lefficienza negli accessi al
disco di grande importanza e ad essa viene dedicata particolare attenzione.
indipendenza dal particolare dispositivo, per semplificare la vita al programmatore e per
poter usare lo stesso programma con (modelli di) dispositivi diversi. Si vuole un trattamento
uniforme dei dispositivi in riferimento sia al modo in cui i processi vedono i dispositivi che
al modo in cui i dispositivi sono gestiti dal SO. Non facile ottenere questa uniformit, a
causa della diversa natura e delle diverse modalit di funzionamento dei dispositivi. Si cerca
di usare un approccio modulare in modo da:
nascondere nelle routine di basso livello gran parte dei dettagli dei dispositivi;
distinguere i dispositivi fisici, cui sono associate le routine di basso livello, dai dispositivi
logici (canali), cui sono associate funzionalit generali di alto livello (open, read, write,
close);
associare un dispositivo fisico a uno logico;
consentire ai processi di interagire con i dispositivi logici.
Il software del SO che realizza lindipendenza dal dispositivo si chiama driver. Un driver controlla
un tipo di dispositivo, ne nasconde i dettagli e consente le operazioni di I/O ai processi tramite
comandi di alto livello. Solitamente costituito da due parti, che operano in modo asincrono,
sincronizzate tramite semafori:
una parte, eseguita dal processo utente, una subroutine di interfaccia (API) che il processo
invoca per richiedere una operazione di I/O (OPEN, CLOSE, READ, ...); le subroutine di
interfaccia tramite una SVC attivano una routine (DOIO) del SO, specificandone i
parametri;
una seconda parte, eseguita dal SO con l'ausilio di una routine di servizio delle interruzioni
(ISR) e un processo di sistema (Device Handler) che, per rendere veloce lesecuzione della
ISR, la affianca e svolge le operazioni non strettamente urgenti.
Quando un processo intende usare un dispositivo (disp) deve:
aprire un canale (ch) associato al dispositivo, chiamando una subroutine di interfaccia, ad
es. OPEN (disp, ch, ...). Questa subroutine porta il SO ad associare al dispositivo fisico disp
il dispositivo logico ch ed a consentirne luso al processo;
richiedere le operazioni di I/O, chiamando una subroutine di interfaccia, ad es. WRITE (ch,
dati, ...). Questa subroutine porta il SO ad eseguire o avviare la corrispondente operazione;
chiudere il canale ch, al termine delluso del dispositivo, tramite una subroutine di
interfaccia ad es. CLOSE(ch, ...). Il SO a questo puntoelimina le associazioni fatte dalla
OPEN.
Le subroutine di interfaccia normalmente contengono una SVC che attiva una routine del SO
(DOIO) che esegue quanto richiesto e pu sospendere il processo richiedente.
La DOIO, attivata direttamente (o indirettamente tramite SVC) dalla subroutine di interfaccia, ha il
compito di predisporre le strutture di dati che servono per eseguire loperazione richiesta, sulla base
dei parametri ricevuti.
Tipicamente la chiamata a una DOIO ha la forma
DOIO (ch, mode, count, pointer, sem);
con:
ch = canale (identificatore di dispositivo logico);
mode = tipo di operazione (open, read, write, );
count = numero di dati da trasferire;
pointer = indirizzo di memoria di origine o di destinazione del trasferimento;
sem = semaforo di supporto (RS - Richiesta Servita) per segnalare quando loperazione di
I/O sar completata..
Per eseguire le operazioni di I/O richieste da un processo, il driver deve disporre di alcune di
informazioni, tra le quali il processo richiedente, il dispositivo logico (canale), il dispositivo fisico,
loperazione da eseguire, i semafori per le sincronizzazioni.
Queste informazioni sono contenute in alcune strutture dati:
il descrittore di processo (PD)
il descrittore di dispositivo (DD)
il descrittore della richiesta di I/O (IORB).
Descrittore di processo: tramite la chiamata OPEN (disp, ch, ...) il SO crea lassociazione tra canale
e dispositivo e la lega al descrittore del processo; successivamente il processo opera utilizzando ch.

Descrittore del dispositivo e IORB: Il descrittore di dispositivo (DD, device descriptor) contiene
informazioni che definiscono le caratteristiche specifiche del dispositivo. Un descrittore di una
richiesta di I/O contiene le informazioni relative ad una specifica richiesta di I/O. La chiamata a
DOIO(ch, mode, ...) completa un IORB e lo aggiunge alla lista di richieste associata al dispositivo
interessato.

Funzionamento del driver
La parte del driver eseguita dal processo utente (sincrona con il processo utente) costituita dalle
subroutine di interfaccia e dalla routine DOIO attivata da esse. La parte del driver eseguita dal
processo di I/O del SO (sincrona con le operazione del dispositivo) costituita dal device handler
(processo di sistema che gestisce lI/O del particolare dispositivo) e dalla routine di servizio delle
interruzioni (ISR) del dispositivo. Le due parti del driver (tra loro asincrone) si sincronizzano
tramite i semafori RA ed RS e comunicano tramite le strutture di dati condivise (in particolare la
lista concatenata di IORB).
A seguito della chiamata
DOIO (ch, mode, count, pointer, sem);
la routine accede al descrittore PD del processo in esecuzione e, tramite il link canali aperti, trova il
dispositivo associato a ch e il relativo descrittore DD. Quindi verifica la validit dei parametri
passati, confrontandoli con le caratteristiche contenute nel DD: se i parametri non sono validi,
termina con uneccezione derrore (che pu provocare la terminazione del processo), altrimenti usa
i parametri per costruire lIORB (I/O Request Block) che descrive la richiesta del processo e lo
inserisce nella lista degli IORB associata al DD. A questo punto esegue una signal sul semaforo RA
(Richiesta Attiva) contenuto nel DD per indicare al device handler che c un nuovo IORB nella
lista del dispositivo ed esegue un wait sul semaforo RS (Richiesta Servita) contenuto nellIORB che
provoca la sospensione del processo fino a che quella richiesta non stata servita.

Di conseguenza lhandler avr il seguente comportamento:

mentre la ISR risulter estremamente semplificata:

(questo esempio riferito ad una operazione di input, come esercizio scrivi la struttura della ISR
relativa ad un dispositivo di output).
Per i dispositivi pi semplici, per i quali le operazioni da eseguire in occasione di una interruzione
sono leggere, si pu rendere pi snella la struttura del driver eliminando il Device Handler e
facendo svolgere le sue funzioni in parte alla DOIO, in parte alla ISR.
In questo caso la DOIO si sincronizza direttamente con la ISR (basta il solo semaforo RS):
la DOIO, costruisce lIORB, lo mette a disposizione della ISR, avvia anche loperazione;
poi attende (wait(RS))
la ISR verifica eventuali errori, esegue tutte le operazioni richieste e poi segnala
(signal(RS)).
Bufferizzazione
Per aumentare l'efficienza del sistema di I/O il SO prevede alcune aree di memoria (buffer) in cui
trasferire i dati di input provenienti dai dispositivi (prima di trasferirli ai processi utente) e i dati di
output (prima di trasferirli ai dispositivi).
In questo modo si riduce l'overhead dovuto alle sincronizzazioni e disponendo di dispositivi DMA
le operazioni di I/O sono pi veloci. Con buffer multipli i dispositivi operano con maggior
efficienza, il dispositivo pu trasferire un blocco di dati mentre il processo ne pu elaborare un altro
in parallelo.
Senza opportuni accorgimenti, con la bufferizzazione il processo potrebbe subire uno swap out,
perch il trasferimento coinvolge page frame del sistema, il che creerebbe problemi seri. Per questo
il SO deve tener traccia dei buffer assegnati ai processi.
A seconda del dispositivo, la bufferizzazione pu essere:
di tipo a blocchi, i buffer sono di dimensione fissa, ad es. di un page frame. I trasferimenti
avvengono per blocchi. usato per dischi, nastri,
di tipo stream: i trasferimenti avvengono per flussi di caratteri, usato per terminali,
stampanti, porte seriali, mouse

Spooling
Un processo che richieda luso di un dispositivo non condivisibile deve attendere che si liberi, nel
caso esso sia gi in uso. Per i dispositivi di I/O (principalmente di output), per evitare queste attese,
il SO utilizza la tecnica di spooling (Simultaneous Peripheral Operation On Line), che consiste
nellassegnare, ad ogni processo che lo richieda, un dispositivo virtuale, realizzato da un file su
disco.
Ciascun processo ottiene, senza attesa, laccesso al file che rappresenta il dispositivo (non
condivisibile), le richieste dei processi di trasferire dati al dispositivo vengono trasformate in
trasferimenti sul file assegnato. Essendo i dischi veloci, lI/O spesso pi rapido, quando un
processo chiude il proprio dispositivo virtuale, il suo file viene inserito nella coda dei file che
saranno trasferiti al dispositivo fisico, uno alla volta, da un processo di sistema (Spooler). La coda
dei file gestiti dallo spooler si mantiene da unattivazione allaltra del sistema.
Gestione dei dischi
I dischi sono molto pi lenti della memoria centrale (tempo di accesso tipico per i dischi: 10ms,
tempo di accesso tipico per la memoria: 10ns). Tuttavia gli accessi al disco sono spesso molto
frequenti sia per le richieste dei processi che per quelle del SO in caso di memoria virtuale. Per
questo motivo le prestazioni complessive del sistema dipendono fortemente dallefficienza dellI/O
su disco.

Il tempo di accesso a un blocco di dati su disco composto da tre componenti:
tempo si seek, il tempo necessario a posizionare la testina di lettura/scrittura sulla traccia,
con valori tipici tra i 5 e i 10 ms;
tempo di latenza, il tempo necessario a posizionare la testina allinizio del settore;
tempo di trasferimento, il tempo necessario a trasferire il blocco di dati.
Le politiche di schedulazione degli accessi al disco mirano a ridurre il tempo di seek.
Scheduling FIFO: le richieste di accesso vengono evase nellordine con cui sono pervenute. Ad
esempio, supponiamo che in un dato istante, si sia formata una coda di richieste di accesso al disco,
relative alle tracce 53, 98, 183, 37, 122, 14, 124, 65, 67 e che la testina si trovi inizialmente sulla
traccia 53. Le richieste vengono evase nellordine di arrivo, come rappresentato nella figura
seguente, e le prestazioni sono molto scarse.

Scheduling SSTF: viene scelta ogni volta come richiesta successiva da evadere, quella situata sulla
traccia pi vicina alla posizione attuale della testina. Il tempo complessivo decisamente pi breve
(e quindi le prestazioni sono migliori) del caso FIFO. Per, se continuano a pervenire richieste per
tracce vicine alla attuale, pu provocare starvation delle richieste pi lontane.

Scheduling SCAN: le richieste vengono evase secondo lordine con cui vengono incontrate dalla
testina, che si sposta nella stessa direzione da una estremit allaltra del disco e inverte la direzione
solo quando ha raggiunto lestremit. Lo scheduling SCAN evita il rischio di starvation ed ha una
buona efficienza, simile a quella del metodo SSTF. Questa politica di scheduling per non equa
perch favorisce le richieste che interessano le tracce situate vicino alle estremit delle superfici del
disco (vengono scandite due volte, avanti e indietro, in tempi ravvicinati) e favorisce anche le
richieste arrivate per ultime. Il primo dei due problemi risolto con la variante CSCAN, il secondo
con la variante N-step SCAN.

Scheduling C-SCAN: le richieste vengono evase solo mentre la testina sta procedendo in una
direzione, mentre il ritorno allaltra estremit avviene senza accessi al disco. Questa politica pi
equa del caso SCAN perch ogni zona del disco scandita con la stessa periodicit, ma anche
meno efficiente.

Scheduling LOOK e C-LOOK: differiscono dagli scheduling SCAN e C-SCAN solo per il fatto
che evitano di procedere in una direzione se non c almeno una richiesta in quella direzione.
Pertanto presentano le stesse caratteristiche dello SCAN e, rispettivamente, dello C-SCAN, ma
risultano pi efficienti.
Scheduling N-step SCAN: una variante dello SCAN intesa ad evitare di privilegiare le richieste
arrivate per ultime (e di penalizzare le altre). Le richieste sono ripartite in sottocode di lunghezza N,
ogni sottocoda viene elaborata, con modo SCAN. Se N = 1 si ricade nel caso FIFO, se N grande le
prestazioni sono simili allo SCAN. Le nuove richieste sono inserite in una sottocoda diversa da
quella in elaborazione, per cui non possono passare avanti. Spesso si usano due sottocode
(FSCAN), le nuove richieste vengono inserite in una, mentre servita laltra.

Sistemi Operativi

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sistemi Operativi

Uploaded by

Copyright:

Available Formats

Maria Teresa Bombi Appunti sui Sistemi Operativi pag.

You might also like