Sistemi Operativi - User contributions [en]

ProvaTeorica 2014.02.22

2017-09-10T12:49:48Z

FedericoB: /* Soluzione di FedericoB */ Corretto nome di variabile nella spiegazione di una soluzione.

Testo: [http://www.cs.unibo.it/~renzo/so/compiti/2014.02.21.tot.pdf]

==Esercizio c.1==

===Soluzione di Coci===

<syntaxhighlight lang="C">
monitor bbwl {
condition oktowrite;
condition oktolog;
condition oktoread;
int logging = 0;
queue q;

procedure entry write (eltype elem) {
if (q.length() == MAXELEM || logging)
oktowrite.wait();
q.enqueue (elem);
logging = 1;
oktolog.signal();
}

procedure entry eltype log() {
if (q.length == 0)
oktolog.wait();
eltype tmp = q.top();
logging = 0;
oktoread.signal();
return tmp;
}

procedure entry eltype read() {
if (q.length == 0 || logging)
oktoread.wait();
eltype tmp = q.dequeue();
oktowrite.signal();
return tmp;
}
}

</syntaxhighlight>

===Soluzione di Save===

<syntaxhighlight lang="C">

condition oktowrite, oktoread, oktolog ;
queue buffer = MAXELEM ;
queue Llogger ;

monitor bbwl
{
procedure entry write (altype elem)
{
if (buffer.length >= MAXELEM)
oktorite.wait() ;
buffer.enqueue(elem);
oktolog.signal () ;
}

procedur entry logger() # logger deve tenere traccia di tutti i pacchetti transitati mettendoli in una sua memoria.
{
if (buffer.length == 0)
oktolog.wait();
Llogger.enqueue(buffer.front()) # restituisci il valore in testa di buffer e inseriscilo in coda a Llogger
ok toread.signal() ;
}

procedure entry read()
{
if (buffer.length == 0)
oktoread.wait();
buffer.dequeue() # restituisci il valore in testa di buffer e rimuovilo.
oktowrite.signal() ;
}
}
</syntaxhighlight>
save

==Esercizio c.2==

===Soluzione di Coci===

alpha(x,y): <x=4, y=sqrt(x)>

il valore che viene salvato in y è sempre 2, quindi non va bene.

bravo(x,y): <y=sqrt(x), x=4>

<pre>
xi yi xf yf
0 0 4 0
0 1 4 1
1 0 4 1
1 1 4 1
</pre>

il valore iniziale di x viene salvato in y, quindi va bene.

charlie(x,y): <y=sqrt(x), x=4*y>

Anche questo va bene, per le stesse ragioni di bravo.

delta(z,t): <z=z xor t, t=z xor t>
<pre>
zi ti zf tf
0 0 0 0
0 1 1 0
1 0 1 1
1 1 0 1
</pre>
Il valore iniziale di z viene salvato in t, quindi va bene.

===Soluzione di Diego.tului===

alpha: non funziona perché y non andrà mai a 0, quindi non entrerà mai in CS.

bravo: funziona perché quando y va a 0 x rimane 4, e perciò finché x non ritorna 0 la CS è occupata.

charlie: dipende dal valore iniziale di x, perché se all'inizio x = 0 (y = 0, x = 4 * 0 = 0) quindi non ci
sarà mutua esclusione.

delta: dipende dal valore iniziale di t, perché se all'inizio è 0, 0 xor 0 resta sempre 0, ergo come sopra.

Diego

===Soluzione di FedericoB===
alpha assegna valori costanti quindi non è possibile utilizzarla per la test and set in quanto il suo risultato non può essere influenzato da parametri esterni.

bravo(lock,vp) assegna a lock 4 e a vp la radice del vecchio lock
Un possibile codice che utilizza bravo è il seguente:
<pre>
int lock=0
process p
int vp;
while(1) {
do {
bravo(lock,vp)
} while (vp==2)
//sezione critica
vp=0
bravo(vp,lock) //assegno a lock 0
}
</pre>
charlie(lock,vp) assegna a lock 4 moltiplicato per la radice del vecchio lock e a vp la radice del vecchio lock
<pre>
int lock=1
process p
int vp;
while(1) {
do {
charlie(lock,vp)
} while (vp!=1)
//sezione critica
vp=1
charlie(vp,lock) //assegno a lock 1
}
</pre>
Ho cambiato il valore iniziale del lock per evitare l'effetto assorbente dello zero.
Inoltre ora quando il lock è impostato i processi in attesa avranno un vp completamente differente tra loro quindi ho dovuto utilizzare una diseguaglianza.

delta(z,t)
<pre>
zi ti zf tf
comb1 0 0 0 0
comb2 0 1 1 0
comb3 1 0 1 1
comb4 1 1 0 1
</pre>
Impossibile perchè nessuna delle combinazioni di input e utilizzabile.
La combinazioni 1 e 3 non cambiano il lock e quindi non ci sarebbe mutua esclusione.
Utilizzando le combinazioni 2 e 3 (quindi con vp inizializzato a 1) non ci sarebbe comunque mutua esclusione perchè
se inizializziamo lock a 0 viene messo dalla combinazione 2 a 1 e vp=0, il primo processo ottiene la sezione critica.
Un altro processo si troverebbe il lock impostato a 1 e vp=1 per inizializzazione locale.
Verrebbe quindi utilizzata la combinazione 4 che però riporterebbe il lock a 0 e quindi un terzo processo potrebbe entrare in sezione critica.

==Esercizio g.1==

===Soluzione di Coci===

Sia n=3 il numero di pagine mantenute in memoria

a) 123456789123456789...

MIN = MINNUM
11144777
2225588
333669

b) 145231231231231...

MINNUM

111232123
44444444
5555555

MIN
111111111
44222222
5333333

Alessandro

===Soluzione di Diego.tului===

Sia n=3 il numero di pagine mantenute in memoria

la soluzione di Alessandro secondo noi presenta dei problemi, la integriamo:

a) 1234431432431432431

111444444444444444
222221112221112221
3333333333333333

ProvaTeorica 2014.02.22

2017-07-16T18:30:09Z

FedericoB: /* Soluzione di FedericoB */ Corretta soluzione a seguito di una segnalazione fatta da un collega

Testo: [http://www.cs.unibo.it/~renzo/so/compiti/2014.02.21.tot.pdf]

==Esercizio c.1==

===Soluzione di Coci===

<syntaxhighlight lang="C">
monitor bbwl {
condition oktowrite;
condition oktolog;
condition oktoread;
int logging = 0;
queue q;

procedure entry write (eltype elem) {
if (q.length() == MAXELEM || logging)
oktowrite.wait();
q.enqueue (elem);
logging = 1;
oktolog.signal();
}

procedure entry eltype log() {
if (q.length == 0)
oktolog.wait();
eltype tmp = q.top();
logging = 0;
oktoread.signal();
return tmp;
}

procedure entry eltype read() {
if (q.length == 0 || logging)
oktoread.wait();
eltype tmp = q.dequeue();
oktowrite.signal();
return tmp;
}
}

</syntaxhighlight>

===Soluzione di Save===

<syntaxhighlight lang="C">

condition oktowrite, oktoread, oktolog ;
queue buffer = MAXELEM ;
queue Llogger ;

monitor bbwl
{
procedure entry write (altype elem)
{
if (buffer.length >= MAXELEM)
oktorite.wait() ;
buffer.enqueue(elem);
oktolog.signal () ;
}

procedur entry logger() # logger deve tenere traccia di tutti i pacchetti transitati mettendoli in una sua memoria.
{
if (buffer.length == 0)
oktolog.wait();
Llogger.enqueue(buffer.front()) # restituisci il valore in testa di buffer e inseriscilo in coda a Llogger
ok toread.signal() ;
}

procedure entry read()
{
if (buffer.length == 0)
oktoread.wait();
buffer.dequeue() # restituisci il valore in testa di buffer e rimuovilo.
oktowrite.signal() ;
}
}
</syntaxhighlight>
save

==Esercizio c.2==

===Soluzione di Coci===

alpha(x,y): <x=4, y=sqrt(x)>

il valore che viene salvato in y è sempre 2, quindi non va bene.

bravo(x,y): <y=sqrt(x), x=4>

<pre>
xi yi xf yf
0 0 4 0
0 1 4 1
1 0 4 1
1 1 4 1
</pre>

il valore iniziale di x viene salvato in y, quindi va bene.

charlie(x,y): <y=sqrt(x), x=4*y>

Anche questo va bene, per le stesse ragioni di bravo.

delta(z,t): <z=z xor t, t=z xor t>
<pre>
zi ti zf tf
0 0 0 0
0 1 1 0
1 0 1 1
1 1 0 1
</pre>
Il valore iniziale di z viene salvato in t, quindi va bene.

===Soluzione di Diego.tului===

alpha: non funziona perché y non andrà mai a 0, quindi non entrerà mai in CS.

bravo: funziona perché quando y va a 0 x rimane 4, e perciò finché x non ritorna 0 la CS è occupata.

charlie: dipende dal valore iniziale di x, perché se all'inizio x = 0 (y = 0, x = 4 * 0 = 0) quindi non ci
sarà mutua esclusione.

delta: dipende dal valore iniziale di t, perché se all'inizio è 0, 0 xor 0 resta sempre 0, ergo come sopra.

Diego

===Soluzione di FedericoB===
alpha assegna valori costanti quindi non è possibile utilizzarla per la test and set in quanto il suo risultato non può essere influenzato da parametri esterni.

bravo(lock,vp) assegna a lock 4 e a y la radice del vecchio lock
Un possibile codice che utilizza bravo è il seguente:
<pre>
int lock=0
process p
int vp;
while(1) {
do {
bravo(lock,vp)
} while (vp==2)
//sezione critica
vp=0
bravo(vp,lock) //assegno a lock 0
}
</pre>
charlie(lock,vp) assegna a lock 4 moltiplicato per la radice del vecchio lock e a vp la radice del vecchio lock
<pre>
int lock=1
process p
int vp;
while(1) {
do {
charlie(lock,vp)
} while (vp!=1)
//sezione critica
vp=1
charlie(vp,lock) //assegno a lock 1
}
</pre>
Ho cambiato il valore iniziale del lock per evitare l'effetto assorbente dello zero.
Inoltre ora quando il lock è impostato i processi in attesa avranno un vp completamente differente tra loro quindi ho dovuto utilizzare una diseguaglianza.

delta(z,t)
<pre>
zi ti zf tf
comb1 0 0 0 0
comb2 0 1 1 0
comb3 1 0 1 1
comb4 1 1 0 1
</pre>
Impossibile perchè nessuna delle combinazioni di input e utilizzabile.
La combinazioni 1 e 3 non cambiano il lock e quindi non ci sarebbe mutua esclusione.
Utilizzando le combinazioni 2 e 3 (quindi con vp inizializzato a 1) non ci sarebbe comunque mutua esclusione perchè
se inizializziamo lock a 0 viene messo dalla combinazione 2 a 1 e vp=0, il primo processo ottiene la sezione critica.
Un altro processo si troverebbe il lock impostato a 1 e vp=1 per inizializzazione locale.
Verrebbe quindi utilizzata la combinazione 4 che però riporterebbe il lock a 0 e quindi un terzo processo potrebbe entrare in sezione critica.

==Esercizio g.1==

===Soluzione di Coci===

Sia n=3 il numero di pagine mantenute in memoria

a) 123456789123456789...

MIN = MINNUM
11144777
2225588
333669

b) 145231231231231...

MINNUM

111232123
44444444
5555555

MIN
111111111
44222222
5333333

Alessandro

===Soluzione di Diego.tului===

Sia n=3 il numero di pagine mantenute in memoria

la soluzione di Alessandro secondo noi presenta dei problemi, la integriamo:

a) 1234431432431432431

111444444444444444
222221112221112221
3333333333333333

Prova teorica 2017.01.18

2017-06-18T20:17:19Z

FedericoB: /* Esercizio g.2 */ aggiunta risposta esercizio 2

[http://www.cs.unibo.it/~renzo/so/compiti/2017.01.18.ris.pdf link al compito]

==Esercizio g.2==

# '''Perché un algoritmo di rimpiazzamento a stack non soffre dell’anomalia di Belady?''' L'anomalia di Belady consiste nel aumento del page fault al aumentare dei frame in memoria. Se un algoritmo è a stack vuol dire che fissato una stringa di riferimento, in qualsiasi instante t l'insieme delle pagine con n frame è un sottoinsieme del insieme della pagine con n+1 frame. Quindi i page fault non possono aumentare perchè comunque è presente il set di pagine che era presente anche con n frame più un addizionale pagina.
# '''Perché si può usare un meccanismo di crittografia simmetrica nella gestione delle capability di accesso alle risorse?''' Possiamo usare la crittografia simmetrica per la gestione delle capability se queste sono salvate nella parte di memoria utente del processo. Non dovendo trasmettere la chiave attraverso la rete possiamo utilizzare crittografia simmetrica.
# '''Quali operazioni svolge il processore per la gestione di un interrupt e quali invece sono a carico del kernel del sistema operativo?''' Il processore si occupa, all'attivazione della linea elettronica dell interrupt di recuperare dalla memoria in locazioni fisse l'indirizzo delle istruzioni di gestione degli interrupt. In seguito carica questo indirizzo nel program counter e quindi "salta" a queste istruzioni attivando la modalità di esecuzione kernel mode. Le routine di gestione degli interrupt fanno parte del codice kernel e si occupano di gestire opportunamente le operazioni necessarie in base al tipo di interrupt. Per esempio operazioni come eseguire lo scheduler o recuperare l'output di un device.
# '''Perche’ il mascheramento degli interrupt non si può utilizzare per creare sezioni critiche in sistemi multicore o multiprocessore?''' Il mascheramento degli interrupt previene l'interruzione del esecuzione del processo corrente e il context switch a un altro processo e di conseguenza la non atomicità delle istruzioni che stava eseguendo il processo. Anche disabilitando gli interrupt (è uguale se su un solo processore o su tutti) c'è comunque la possibilità che altro codice eseguito in ''parallelismo reale'' vada in concorrenza con quello dove si sta cercando di ottenere una sezione critica.
# '''Per quali tipi di processo l’algoritmo di schedulazione round-robin è efficiente e per quali no?''' L'algoritmo di schedulazione round-robin è efficente per i processi I/O bound in quanto è ''fair'', cioè permette a tutti i processi il diritto di esecuzione entro un certo lasso di tempo. Può non essere efficiente per i processi CPU bound che hanno tempi di esecuzione lunghi e il round robin li costringe a ritardare il loro completamento. Inoltre un processo CPU bound potrebbe essere interrotto quando manca davvero poco al suo termine ma il time slice è terminato oppure necessita di I/O.Il processo viene messo in coda e bisognerà aspettare l'esecuzione di tutti gli altri processi prima di poter finire l'esecuzione.Uno scheduler shortest remaining time first avrebbe invece rimesso subito in esecuzione il processo CPU bound se il tempo di esecuzione previsto rimanente era davvero ridotto.

Prova teorica 2017.05.29

2017-06-18T20:12:20Z

FedericoB: /* Esercizio g.2 */ aggiunte risposte domande 1, 3 e 4

[http://www.cs.unibo.it/~renzo/so/compiti/2017.05.29.tot.pdf link al compito]

==Esercizio c.1==

===Soluzione di Save===

se qualcuno può correggermi o confermare il rispetto delle regole concorrenziali, mi fa un grande piacere.
saluti

<syntaxhighlight lang="C">
Monitor rubaBandiera () {

condition oktochiama, oktopunteggio, oktopronto;

listnum [] = [1,2,3,4]
numeri[]
numeriChiamati[0...MAX-1]
studentiPronti = True;

punteggio [A] = 0;
punteggio [B] = 0;

procedure entry gioco() {

n=random(listnum);
numeri(n)=random(numeriChiamati);

if( studentiPronti == false)

oktochiama(numeri).wait() ;

studentiPronti(numeri) = false ;
oktopunteggio.signal();
}
procedure entry studente () {

while(studentiPronti(numeri))

oktochiama(numeri).signal();
}

procedure entry chiama () {

print(punteggio[A] ":" punteggio[B]);
if (studentiPronti(numeri))

oktopunteggio.wait()

if (allabadiera(A))
punteggio[A] ++;
else punteggio [B]++;
print(punteggio[A] ":" punteggio[B]);
studentiPronti(numeri) = true

pronto();

procedure entry pronto() {

if(punteggio[A] || punteggio[B] < 10)

return 0;
else return 1;
}}

</syntaxhighlight>
Secondo devi utilizzare il nome corretto per le procedure entry, cioè mancano nuovapartita e allabandiera, che non hai definito. Con i corretti parametri. --[[User:FedericoB|FedericoB]] ([[User talk:FedericoB|talk]]) 18:45, 15 June 2017 (CEST)
===Soluzione di Stefano Zaniboni===

<syntaxhighlight lang="C">
Monitor rb () {

condition ok2chiama, ok2run[MAX], ok2fine
int npronti, punteggio[2], arrivati, c

procedure entry void nuovapartita() {
c = npronti = arrived punteggio[0] = punteggio[1] = 0
}
procedure entry int chiama(int *chiamati) {
c = chiamati.length
if(npronti < 2 * MAX)
ok2chiama.wait()
for(int i = 0; i < c; i++){
ok2run[i].signal()
ok2run[i].signal()
}
ok2fine.wait()
if(max(punteggio) == 10)
for(int i = 0; i in range(MAX); i++){
ok2run[i].signal()
ok2run[i].signal()
}
return punteggio;
}

procedure entry int pronto(int squadra, int numero) {
if(max(punteggio) == 10)
return -1
npronti++
if (npronti > 2 * MAX)
ok2chiama.signal()
if(n not in chiamata)
ok2run[n].wait()
npronti--
if(max(punteggio) == 10)
return -1
else return 0
}

procedure entry void allabandiera(int squadra, int numero) {
arrived++
if(arrived = 2 * c)
punteggio[1 - squadra]++
ok2fine.signal()
}
}

</syntaxhighlight>

==Esercizio c.2==

===Soluzione di Stefano Zaniboni===
<syntaxhighlight lang="C">
/*
sia dato un servizio di message passing asincrono distratto. Questo servizio si comporta come un servizio di message passing asincrono ma talvolta dimentica la destinazione.
E’ però possibile indicare un processo come “ufficio messaggi smarriti” al quale verranno recapitati tutti i messaggi per i quali il servizio distratto ha dimenticato la destinazione.

Void dmsgsend(pid_t dest, msg_t msg); //si comporta come amsgsend ma può dimenticare la desticazione
msg_t dmsgrecv() //si comporta come amsgrecv(*)
void dset_lost_n_found(pid_t pid); //indica il processo per i messaggi smarriti.

Usando il servizio “distratto” e un processo “ufficio messaggi smarriti”,
implementare un servizio di message passing standard (senza la selezione del mittente in ricezione, la amsgrecv riceve da qualsiasi mittente).
*/

void asend(pid_t dest, msg_t msg){
dmsgsend(dest,{getpid(), dest, msg})
}

msg_t arecv(pid_t sender){
{snd, dst, m} = dmsgrecv()
return m
}

process l+f{
dset_lost_n_found(getpid())
while(true){
{snd, dst, m} = dmsgrecv()
if dst != getpid(){
asend(dst, {snd, dst, m})
}
}
}

</syntaxhighlight>

==Esercizio g.1==
===Soluzione di GiovanniF===

min = lifo 1234123124123124...

lifo = lru 123124123124123124...

--[[User:FedericoB|FedericoB]] ([[User talk:FedericoB|talk]]) 10:17, 16 June 2017 (CEST) 
Ho verificato la soluzione: 
Il ragionamento da fare qui è: 
MIN = LIFO 
MIN sceglie la pagina che più tardi nel futuro verrà richiesta 
LIFO sceglie l'ultima pagina caricata 
Quindi ad ogni page fault l'ultima pagina caricata deve essere quella che più tardi nel futuro verrà richiesta

<pre>
MIN
1 2 3 4 1 2 3 1 2 4 1 2 3 1 2 4
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
3 4 4 4 3 3 3 4 4 4 3 3 3 4
# # # # #

LIFO
1 2 3 4 1 2 3 1 2 4 1 2 3 1 2 4
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
2 2 2 2 2 2 2 2 2 1 2 2 2 2 2
3 4 4 4 3 3 3 4 4 4 3 3 3 4
# # # # #
</pre>

LIFO = LRU 
LRU sceglie la pagina che più precedentemente nel passato è stata richiesta 
Quindi ad ogni page fault l'ultima pagina caricata deve essere quella che più precedentemente nel passato è stata richiesta

<pre>
LRU
1 2 3 1 2 4 1 2 3 1 2 4 1 2 3
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
2 2 2 2 2 2 2 2 2 2 2 2 2 2
3 3 3 4 4 4 3 3 3 4 4 4 4
# # # #

LIFO
1 2 3 1 2 4 1 2 3 1 2 4 1 2 3
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
2 2 2 2 2 2 2 2 2 2 2 2 2 2
3 3 3 4 4 4 3 3 3 4 4 4 4
# # # #
</pre>

==Esercizio g.2==
#'''Un i-node di un file system tipo ext2 per un errore viene riportato un numero di link maggiore del reale. Cosa può succedere se si continua ad usare il file system? (perchè?) E se il numero di link errato fosse il contrario inferiore al reale cosa potrebbe succedere? (perchè?) ''' Che quando i reali link al i-node verrano eliminati e il numero decrementato questo non raggiungerà mai zero e lo spazio non verrà rilasciato. Se invece il numero di link è inferiore al reale può succedere che con solo l'eliminazione di pochi link al inode l'area del file venga segnata come libera perchè il sistema operativo pensa che l'inode non sia più utilizzato.
#'''Perchè è necessario usare spinlock in sistemi multiprocessore per implementare kernel di tipo simmetrico (SMP)?''' Perchè la semplice disabilitazione degli interrupt non sarebbe sufficiente in caso di parallelismo reale a prevenire l'accesso a memoria condivisa in concorrenza. Bisogna perciò utilizzare strumenti come gli spinlock che grazie a istruzioni atomiche, per esempio la test-and-set, bloccano l'esecuzione di un processo fino al verificarsi di una condizione. Per evitare il busy wait si possono usare gli spinlock solo per rendere atomiche le istruzioni P e V di un semaforo in modo che la maggior parte del tempo di attesa per entrare in una sezione critica un processo lo passi in stato di wait invece che consumare inutilmente cicli di CPU.
#'''Perchè nei sistemi reali l'algoritmo di rimpiazzamento second chance (orologio) viene preferito a LRU sebbene il primo non sia a stack e il secondo sì?''' perchè la gestione dei timestamp richiesti da LRU è costosa nella MMU.
#'''Perchè revocare un'autorizzazione espressa come capability è più difficile che revocare lo stesso diritto quando espresso come access control list?''' Perchè le capability sono salvate al interno dello spazio di memoria di ciascun processo mentre le access control list sono legate al file.

Prova teorica 2017.05.29

2017-06-16T08:17:10Z

FedericoB: /* Esercizio g.1 */ Aggiunta convalida soluzione es g.2

Prova teorica 2016.05.30

2017-06-16T07:32:24Z

FedericoB: Creata pagina con soluzione esercizio g.1 e risposta a 2 domande esercizio g.2

[http://www.cs.unibo.it/~renzo/so/compiti/2016.05.30.ris.pdf link al compito]

==Esercizio g.1==
<pre>
a) Sia data una memoria di 3 frame. Trovate una stringa di riferimenti di lunghezza infinita tale che se confrontiamo FIFO e MIN, da
un certo istante in poi il numero di page fault per FIFO sia almeno doppio di quello di MIN.
Dimostrate che la proprieta’ sia verificata.
b) Trovate una stringa di riferimenti di lunghezza infinita tale che se confrontiamo FIFO e MIN,
da un certo istante in poi il numero di page fault per FIFO sia almeno triplo di quello di MIN.
Dimostrate che la proprietà sia verificata.
c) (extra/hint) E’ possibile soddisfare b con una memoria di 3 frame? Perché?
</pre>
===Soluzione di FedericoB===
a) la stringa di riferimento 12341234123412341234...
<pre>
FIFO
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
1 1 1 4 4 4 3 3 3 2 2 2 1 1 1 4
2 2 2 1 1 1 4 4 4 3 3 3 2 2 2
3 3 3 2 2 2 1 1 1 4 4 4 3 3
# # # # # # # # # # # # #

MIN
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2
2 2 2 2 2 3 3 3 3 3 3 3 3 3 4
3 4 4 4 4 4 4 4 4 4 1 1 1 1
# # # # #
</pre>
b) la stringa di riferimento per il punto (a) genera il triplo dei page fault su FIFO rispetto a MIN.

c) Sì è possibile ma non è possibile farne il quadruplo.Questo perchè MIN è l'algoritmo teorico ottimale che genera meno page fault possibili. MIN sostituisce la pagina che più tardi nel futuro verrà richiesta. Data una stringa di riferimento che genera page fault ad ogni richiesta con FIFO, quindi in cui non ci sono mai richieste uguali consecutive, con MIN se dobbiamo ottenere un terzo dei page fault vuol dire avere un page fault minimo ogni 3 richieste. Con una memoria di 3 frame se una frame viene occupato dalla nuova pagina vuol dire che rimangono 2 frame in cui rimarranno pagine che verrano utilizzate nell'immediato futuro, quindi potremo avere 2 richieste che non genereranno page fault, ma sicuramente alla terza richiesta verrà generato.
Se avessimo una memoria con 4 frame potremmo avere un quarto dei page fault rispetto a FIFO.

==Esercizio g.2==

===Soluzione di FedericoB===
'''1. A cosa serve il processo IDLE (che mette il processore in wait state se possibile o esegue un loop infinito)? Quando viene messo in esecuzione? Come si gestisce l’attivazione di IDLE negli scheduler a priorità e nel round-robin?'''

Il processore normalmente ad ogni istruzione incrementa il program counter di una posizione oppure esegue un salto. Quindi non è tecnicamente possibile non fargli eseguire nulla. Il processo IDLE serve proprio nelle situazioni in cui non sono presenti processi da eseguire. Lo stato di wait riduce il consumo energetico del processore, ne abbassa la frequenza. Negli scheduler a priorità il processo IDLE può essere un processo con priorità minima. Nel round robin invece conviene inserire il processo IDLE solo se si rileva che la coda ready è vuota. Altrimenti se fosse sempre presente nella coda ready saremmo costretti ad eseguire il processo IDLE ad ogni turn-around della coda circolare e questo decrementerebbe le prestazioni.

'''2. Lo stato unsafe è condizione necessaria ma non sufficiente perché possa verificarsi deadlock. Quali sono I passi logici necessari per dimostrare questa affermazione?'''

Bisogna dimostrare che se si verifica deadlock allora si è sicuramente verificato anche uno stato unsafe. Se si verifica deadlock vuol dire che ci sono processi in attesa di risorse. Uno stato unsafe è uno stato in cui il sistema non ha potuto soddisfare nessuna delle richieste perchè non ha risorse da assegnare, quindi i processi devono rimanere in attesa. Se non si fosse in uno stato di unsafe allora il sistema potrebbe garantire una risorsa a uno dei processi in deadlock e questo sbloccherebbe anche tutti gli altri.

'''3. Quali metodi di allocazione per file system ammettono la creazione di file di grandezza arbitrario?'''

'''4. Perché per utilizzare le capability come strumento di autorizzazione è sufficiente usare un metodo crittografico a singola
chiave?'''

Prova teorica 2017.05.29

2017-06-15T20:26:38Z

FedericoB: Aggiunto link al compito ora che il prof ha caricato il pdf

Prova teorica 2017.01.18

2017-06-15T20:22:15Z

FedericoB: /* Esercizio g.2 */ aggiunta risposta domanda 1

[http://www.cs.unibo.it/~renzo/so/compiti/2017.01.18.ris.pdf link al compito]

==Esercizio g.2==

# '''Perché un algoritmo di rimpiazzamento a stack non soffre dell’anomalia di Belady?''' L'anomalia di Belady consiste nel aumento del page fault al aumentare dei frame in memoria. Se un algoritmo è a stack vuol dire che fissato una stringa di riferimento, in qualsiasi instante t l'insieme delle pagine con n frame è un sottoinsieme del insieme della pagine con n+1 frame. Quindi i page fault non possono aumentare perchè comunque è presente il set di pagine che era presente anche con n frame più un addizionale pagina.
# '''Perché si può usare un meccanismo di crittografia simmetrica nella gestione delle capability di accesso alle risorse?'''
# '''Quali operazioni svolge il processore per la gestione di un interrupt e quali invece sono a carico del kernel del sistema operativo?''' Il processore si occupa, all'attivazione della linea elettronica dell interrupt di recuperare dalla memoria in locazioni fisse l'indirizzo delle istruzioni di gestione degli interrupt. In seguito carica questo indirizzo nel program counter e quindi "salta" a queste istruzioni attivando la modalità di esecuzione kernel mode. Le routine di gestione degli interrupt fanno parte del codice kernel e si occupano di gestire opportunamente le operazioni necessarie in base al tipo di interrupt. Per esempio operazioni come eseguire lo scheduler o recuperare l'output di un device.
# '''Perche’ il mascheramento degli interrupt non si può utilizzare per creare sezioni critiche in sistemi multicore o multiprocessore?''' Il mascheramento degli interrupt previene l'interruzione del esecuzione del processo corrente e il context switch a un altro processo e di conseguenza la non atomicità delle istruzioni che stava eseguendo il processo. Anche disabilitando gli interrupt (è uguale se su un solo processore o su tutti) c'è comunque la possibilità che altro codice eseguito in ''parallelismo reale'' vada in concorrenza con quello dove si sta cercando di ottenere una sezione critica.
# '''Per quali tipi di processo l’algoritmo di schedulazione round-robin è efficiente e per quali no?''' L'algoritmo di schedulazione round-robin è efficente per i processi I/O bound in quanto è ''fair'', cioè permette a tutti i processi il diritto di esecuzione entro un certo lasso di tempo. Può non essere efficiente per i processi CPU bound che hanno tempi di esecuzione lunghi e il round robin li costringe a ritardare il loro completamento. Inoltre un processo CPU bound potrebbe essere interrotto quando manca davvero poco al suo termine ma il time slice è terminato oppure necessita di I/O.Il processo viene messo in coda e bisognerà aspettare l'esecuzione di tutti gli altri processi prima di poter finire l'esecuzione.Uno scheduler shortest remaining time first avrebbe invece rimesso subito in esecuzione il processo CPU bound se il tempo di esecuzione previsto rimanente era davvero ridotto.

Prova teorica 2017.05.29

2017-06-15T16:45:54Z

FedericoB: /* Esercizio c.1 */

[[Media:20170529.jpg | link al compito]]

Ho caricato questa foto del compito intanto che non è ancora disponibile il pdf. Quando sarà disponibile sostituire con il link al pdf. --[[User:FedericoB|FedericoB]] ([[User talk:FedericoB|talk]]) 11:41, 15 June 2017 (CEST)

==Esercizio c.1==

===Soluzione di Save===

se qualcuno può correggermi o confermare il rispetto delle regole concorrenziali, mi fa un grande piacere.
saluti

<syntaxhighlight lang="C">
Monitor rubaBandiera () {

condition oktochiama, oktopunteggio, oktopronto;

listnum [] = [1,2,3,4]
numeri[]
numeriChiamati[0...MAX-1]
studentiPronti = True;

punteggio [A] = 0;
punteggio [B] = 0;

procedure entry gioco() {

n=random(listnum);
numeri(n)=random(numeriChiamati);

if( studentiPronti == false)

oktochiama(numeri).wait() ;

studentiPronti(numeri) = false ;
oktopunteggio.signal();
}
procedure entry studente () {

while(studentiPronti(numeri))

oktochiama(numeri).signal();
}

procedure entry chiama () {

print(punteggio[A] ":" punteggio[B]);
if (studentiPronti(numeri))

oktopunteggio.wait()

if (allabadiera(A))
punteggio[A] ++;
else punteggio [B]++;
print(punteggio[A] ":" punteggio[B]);
studentiPronti(numeri) = true

pronto();

procedure entry pronto() {

if(punteggio[A] || punteggio[B] < 10)

return 0;
else return 1;
}}

</syntaxhighlight>
Secondo devi utilizzare il nome corretto per le procedure entry, cioè mancano nuovapartita e allabandiera, che non hai definito. Con i corretti parametri. --[[User:FedericoB|FedericoB]] ([[User talk:FedericoB|talk]]) 18:45, 15 June 2017 (CEST)

==Esercizio c.2==

==Esercizio g.1==
#'''Soluzione di GiovanniF

min = lifo 1234123124123124...

lifo = lru 123124123124123124...

==Esercizio g.2==
#'''Un i-node di un file system tipo ext2 per un errore viene riportato un numero di link maggiore del reale. Cosa può succedere se si continua ad usare il file system? (perchè?) E se il numero di link errato fosse il contrario inferiore al reale cosa potrebbe succedere? (perchè?)
#'''Perchè è necessario usare spinlock in sistemi multiprocessore per implementare kernel di tipo simmetrico (SMP)?''' Perchè la semplice disabilitazione degli interrupt non sarebbe sufficiente in caso di parallelismo reale a prevenire l'accesso a memoria condivisa in concorrenza. Bisogna perciò utilizzare strumenti come gli spinlock che grazie a istruzioni atomiche, per esempio la test-and-set, bloccano l'esecuzione di un processo fino al verificarsi di una condizione. Per evitare il busy wait si possono usare gli spinlock solo per rendere atomiche le istruzioni P e V di un semaforo in modo che la maggior parte del tempo di attesa per entrare in una sezione critica un processo lo passi in stato di wait invece che consumare inutilmente cicli di CPU.
#'''Perchè nei sistemi reali l'algoritmo di rimpiazzamento second chance (orologio) viene preferito a LRU sebbene il primo non sia a stack e il secondo sì?
#'''Perchè revocare un'autorizzazione espressa come capability è più difficile che revocare lo stesso diritto quando espresso come access control list?'''

Prova teorica 2015.09.14

2017-06-15T14:45:42Z

FedericoB: Creata pagina e aggiunta risposta a domanda 2 e 3 dell'esercizio g.2

[http://www.cs.unibo.it/~renzo/so/compiti/2015.09.14.ris.pdf link al compito]

==Esercizio g.2==

===Soluzione di FedericoB===

# '''In quali casi si usano ancora oggi I file system con metodo di allocazione contigua?'''
# '''Come viene usato l'algoritmo della media esponenziale nello scheduler shortest job first? La media esponenziale dipende da un parametro (normalmente indicato con alpha, di valore fra zero e uno). A cosa serve questo parametro?''' Serve a fare una previsione della durata del prossimo intervallo di esecuzione di un processo. Lo scheduler shortest job first sceglie il processo che ha tempo previsto di esecuzione minore. La media esponenziale viene calcolata basandosi sulla durata del precendente intervallo di esecuzione passati e sulla precedente media esponenziale calcolata per lo scorso intervallo. Il parametro alpha assume valori nell'intervallo [0,1]. Più il valore di alpha è vicino a 1 più ci si basa su recenti misurazioni mentre più alpha è uguale a 0 più ci si basa su previsioni che si portano dietro misurazioni del passato.
# '''Lo stato unsafe e' condizione necessaria ma non sufficiente perche' possa verificarsi deadlock. Quali sono I passi logici necessari per dimostrare questa affermazione?''' Bisogna dimostrare che se si verifica deadlock allora si è sicuramente verificato anche uno stato unsafe. Se si verifica deadlock vuol dire che ci sono processi in attesa di risorse. Uno stato unsafe è uno stato in cui il sistema non ha potuto soddisfare nessuna delle richieste perchè non ha risorse da assegnare, quindi i processi devono rimanere in attesa. Se non si fosse in uno stato di unsafe allora il sistema potrebbe garantire una risorsa a uno dei processi in deadlock e questo sbloccherebbe anche tutti gli altri.
# '''Due sistemi gestiscono file system di grandi dimensioni (per es. 10 Terabyte di dati). Il primo usa file system di tipo ext2, il secondo di tipo ext3. Per un guasto al gruppo di continuita' entrambi i sistemi vengono spenti senza un appropriato shutdown. Cosa cambia alla riaccensione? Perche'?'''

Prova teorica 2016.07.27

2017-06-15T13:57:35Z

FedericoB: Creata pagina e aggiunta risposta a due domande del esercizio g.2

[http://www.cs.unibo.it/~renzo/so/compiti/2016.07.27.ris.pdf link al compito]

==Esercizio g.2==

===Soluzione di FedericoB===

'''Le seguenti affermazioni sono vere o false? (spiegarne il motivo).'''
# '''Usando un file system con journaling anche se un sistema viene spento senza fare la procedura di shutdown non si perdono dati.'''
# '''La crittografia a chiave pubblica (doppia chiave) puo’ essere usata al posto di quella a singola chiave e quindi quest’ultima sta cadendo in disuso.'''
# '''Gli scheduler a priorita’ sono particolarmente indicati per i programmi interattivi.''' Vero, in quanto si può assegnare un elevata priorità a un processo I/O Bound e una priorità inferiore a un processo CPU Bound in modo da evitare l'effetto convoglio. Il processo CPU Bound non rischierebbe la starvation perchè nel caso un processo I/O Bound abbia tempi di esecuzione complessivamente lunghi, gli verrebbe ridotta la priorità tramite aging. Per esempio il processo X di Linux ha elevata priorità in quanto deve gestire l'aggiornamento dell'ambiente grafico.
# '''Deadlock prevention e avoidance sono la stessa cosa.''' Falso, la prevention elimina il deadlock ''strutturalmente'' rendendo falsa una o più delle condizioni necessarie al deadlock cioè risorse non condivisibili, bloccanti, non prerilasciabili e l'attesa circolare (di solito si agisce su questa trovando i Knot e uccidendo i processi). L'avoidance invece opera ritardando un operazione per cui si è visto che può causare deadlock. (algoritmo del banchiere, ritardare l'attribuzione di una risorsa).

Prova teorica 2015.06.17

2017-06-15T13:34:50Z

FedericoB: Creata pagina con soluzione a esercizio g.1

[[http://www.cs.unibo.it/~renzo/so/compiti/2015.06.17.ris.pdf link al compito]]

==Esercizio 1===
<pre>
Sia dato il seguente stato dell'algoritmo del Banchiere Multivaluta
Valuta A: COH=x Valuta B: COH=y
p1: credito=6 assegnati=4 credito=10 assegnati=5
p2: credito=6 assegnati=3 credito=5 assegnati=3
p3: credito=6 assegnati=2 credito=10 assegnati=4
Denotare l'insieme di tutti I valori (x, y) per I quali lo stato sopra indicato risulta safe
</pre>
===Soluzione di FedericoB===

<pre>
Assumo che per credito si intenda il credito residuo e non il limite di credito del cliente.
Lo stato è safe se almeno uno dei clienti è soddisfacibile.
Determino un valore di COHx e COHy per cui una sequenza è soddisfacibile e COHx-1 e COHy-1 non è più soddisfacibile.
Inizio ponendo COHx e COHy pari al minimo del credito
Verifico per la valuta x
avail[1] = 6 6>=6? yes
avail[2] = 6+2 = 8 >= 6? yes
avail[3] = 8+3 = 11 >= 6? yes
avail[4] = 11+4 = 16 >= 6? yes
se COHx fosse uguale a 5 nessun cliente sarebbe soddisfacibile.
Per y invese se COHy=5
avail[1] = 5 5>=5? yes
avail[2] = 5+3 = 8 >= 10? No stato unsave
Porto COHY=7
avail[1] = 7 7>=5? yes
avail[2] = 7+3 = 10>=10? yes
avail[3] = 10+4 = 14>=10? yes
avail[4] = 14+5 = 19>=10? yes

Quindi lo stato risulta safe per ogni (x,y) tale che x>5 e y>6
</pre>

Lezioni Anno Accademico 2016/17

2017-06-15T12:15:55Z

FedericoB: /* Lezione del 7 marzo 2017 */

''scrivete qui idee, riassunti dei concetti espressi, commenti approfondimenti sulle lezioni.''

== Lezione del 23 settembre 2016 ==

'''YY'''

* Presentazione del corso.
* Strumenti del corso: web, wiki.mailing list
* Indice dei contenuti
* Prove di esame (Scritto, Prova Pratica, Progetto).

* Hardware Software
* Informatica
* Informazione/Dato
* Rivoluzione digitale (secondo rinascimento, Terza rivoluzione Industriale).
* Software Libero

== Lezione del 27 settembre 2016 ==

'''OS:Y'''

* '''Organizzazione (martedi' vs. venerdi')'''
In genere la lezione del martedì sarà più teorica mentre quella del venerdì più orientata agli aspetti pratici di laboratorio. Questa suddivisione potrebbe cambiare in quanto qualche martedì verrà saltato.
* '''Università'''
Università = studenti + docenti
* '''Digitale/Analogico'''
Digit significa cifra. Nell'informatica è fondamentale il passaggio dal continuo al discreto.
* '''Binario/Decimale'''
Nei calcolatori l'informazione è memorizzata utilizzando il sistema binario ...
(''in quanto in passato i relè consentivano di avere due stati: " 1 e 0 "'': è impreciso, qualcuno sa dare una definizione migliore? [[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 12:00, 29 September 2016 (CEST)) 
In quanto è molto semplice implementare le operazioni aritmetiche con dei circuiti elettronici utilizzando la codifica binaria. Per esempio è possibile creare un [https://it.wikipedia.org/wiki/Half-adder circuito] che somma due bit con riporto con solo due porte logiche. [[User:FedericoB|FedericoB]] ([[User talk:FedericoB|talk]]) 17:05, 29 September 2016 (CEST)
* '''I linguaggi e i problemi dell'Informatica'''
**Processing dell'informazione (Linguaggi di programmazione)
**Comunicazione (Il problema che i dati che mi servono sono in un altro luogo) (Linguaggi dei protocolli di rete, che però sono dei linguaggi temporizzati)
**Memorizzazione (Il problema che i dati mi serviranno in futuro) (Linguaggio del formato dei dati)
* '''Conoscenze a lungo, medio e breve termine nell'Informatica.'''
**BREVE: tecnologia, determinati programmi di sviluppo.
**MEDIO: singoli linguaggi, singoli OS, protocolli di comunicazione.
**LUNGO: algoritmi, informatica teorica, fondamenti costruttivi di reti e di OS.

* '''Cos'è una distribuzione'''
E' un antologia di applicazioni e librerie in modo che siano compatibili tra loro.

* '''Sistema Operativo: perché'''
Un sistema operativo è un programma che controlla l’esecuzione di programmi applicativi e agisce come interfaccia tra le applicazioni e l’hardware del calcolatore. 
E' uno strumento software complesso ed implementabile in diversi modi (monolitico, microkernel, etc.). I microcontroller non hanno OS.
Permette: contabilità delle risorse (consente a sua volta attività di benchmarking); continuità dei servizi; controllo errori
(programmi, dispositivi); multiuser (gli utenti hanno diversi diritti e proprietà sulle risorse); protezione delle attività dei
processi; astrazione file system.
* '''Struttura a livelli (layer)'''

---------------
---------------
---------------
OS
---------------L'
hw
---------------L

Consente di: separare la complessità, di avere portabilità.
Ogni livello rappresenta un cambio di linguaggio.
Più aggiungiamo livelli più aumenta il livello di astrazione.
* '''Programma/processo'''
Algoritmo: sequenza finita di istruzioni non ambigue, atta a risolvere un problema.

Programma: traduzione degli algoritmi in un linguaggio di programmazione.

Processo: istanza esecutiva di un programma. Il programma è testo statico, quando viene eseguito diviene processo. Possiamo avere
uno stesso programma in esecuzione su più processi (e.g apertura di più terminali che eseguono un editor di testo).

System call: richieste di processi al OS. e.g. printf (visto nel codice compilato in assembly tramite gcc -s), invoca write().
vi è una sequenza di azioni del tipo: richiesta di stampa al kernel --> attesa --> risposta.
* '''Storia dell'Informatica prima dei transistor'''

La storia dei calcolatori non ha un inizio preciso. Nel 1900 venne trovato sul relitto di una nave greca risalente al II secolo a.C un meccanismo in grado di calcolare i movimenti degli astri, si ipotizza con una sorprendente meccanica. Oggi questo sistema viene conosciuto come Macchina di Anticitera. Negli ultimi anni di ricerche archeologiche e storiche è venuta sempre più in superficie una vena pionieristica nel mondo classico per quanto riguarda lo studio sul calcolo automatizzato e addirittura di automi (si veda Erone di Alessandria). Ma facciamo un salto in avanti di qualche secolo... 
Già nel XVII secolo Pascal teorizza e mette in pratica uno strumento in grado di addizionare e sottrarre, e nel 1672 G.W. von Leibniz lo perfeziona con l'aggiunta della moltiplicazione e della divisione. Ma è solamente nei primi anni del 1800 che entra in scena la macchina analitica di Babbage. Estremamente complessa, la macchina era dotata di un sistema di input e di elaborazione dati e di un sistema di output. Ed è con Babbage che nascono le schede perforate. La macchina analitica venne presentata per la prima volta in Italia, durante un convegno torinese del 1840. Tra i vari collaboratori scientifici alla macchina è da annotare la presenza di Luigi Federico Menabrea, che tra le altre cose fu Ministro della Marina Militare, ingegnere e Presidente del Consiglio dei Ministri del Regno d'Italia (1867-1869). Il primo vero programmatore della storia, collaboratrice di Babbage, è Ada Lovelace (figlia del poeta Lord Byron!): progettò un algoritmo in grado di elaborare i numeri di Bernulli. 
Nel 1896 viene fondata la Tabulating Machine Company (futura IBM) e agli albori del '900, vari scienziati (trai quali Thomas Edison e Guglielmo Marconi) portarono avanti gli studi sulla valvola termoionica, elemento indispensabile dei primi calcolatori elettronici. La valvola incrementò vertiginosamente i tempi di calcolo ma l'estrema fragilità della stessa causò una serie di problematiche che si risolsero solamente con l'entrata in gioco del transistor.

== Lezione del 30 settembre 2016 ==

'''YC'''

(Storia dopo l'avvento del transistor)

Tre innovazioni indipendenti:
* Multitasking: Inizialmente ideato per mantenere la CPU occupata con altri processi mentre si faceva Input/Output. Permette di dare l'idea al utente di poter eseguire più processi contemporaneamente anche se questi in realtà sono eseguiti dalla cpu in modo intervallato. Ci sono certi computer che hanno più esecutori e quindi possono realmente eseguire multipli processi contemporaneamente.
* Supporto Multiuser
* Interattività:l'interazione con l'utente cambia il flusso del programma.

Queste tre proprietà sono ortogonali quindi possono esistere nei sistemi varie combinazioni di queste.

Iniziano anche a separarsi i ruoli tra programmatori e utenti.Prima i computer venivano utilizzati solo da chi creava programmi ora anche da chi li utilizza senza avere le conoscenze per crearli.

Il Time Sharing.

Sistemi Paralleli (SIMD/MIMD)
Sistemi Real Time

Dal 1969: UNIX.

Il linguaggio C e la portabilità dei sistemi operativi.
Caratteristiche del linguaggio C:
* grande controllo sul codice generato
* costrutti per l'elaborazione a basso livello
* supporto per la programmazione strutturata
* linguaggio "leggero": poche parole chiave, I/O gestito tramite librerie
* Il compilatore C è scritto in C.

Portabilità di un compilatore. I cross-compiler.

Il comando UNIX cc (o gcc): un comando unico per attivare l'intera toolchain per generare un eseguibile.

Il punto e virgola trasforma espressioni in istruzioni (terminatore).

1975? l'avvento dei personal computer. (in realtà il primo PC forse e' la Perrottina Olivetti del 1964).

Compiti a casa:
Portare esperimenti in C ritenuti "difficili".

[[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 10:41, 1 October 2016 (CEST)

== Lezione del 7 ottobre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7TzJXUTJZM3RBUlE 7\10\16]
* '''Esempi di programmi in linguaggio C'''
Abbiamo commentato i programmi dal 1.1 al 1.7 che si possono trovare in questa [[2016-17_Programmi_C|pagina]].
* '''Economia Push/Economia Pull'''
Nell'economia push si basa la produzione sulla previsione di domanda e la si cerca di aumentare tramite la pubblicità. Questa è stata la principale metodologia utilizzata nei secoli scorsi.
Al giorno d'oggi si sta facendo avanti un differente approccio chiamato "economia pull" dove la produzione è basata sulla domanda effettiva. Per esempio per richiedere un finanziamento per l'economia push l'approccio comune è tramite una banca a cui si chiede un prestito in base alle previsioni di ricavo. Invece nell'economia pull è esemplare il fenomeno del crowdfounding dove si riceve un finanziamento dalla "folla" cioè da un gruppo di persone che dona una piccola parte di denaro ciascuna in base al reale interesse per il prodotto/servizio.
* '''Sistemi Operativi e parallelismo'''
Più processi si dicono in esecuzione concorrente quando accedono a risorse condivise.
Un programma è multithread quando tutti i thread condividono la stessa memoria. Ogni thread deve avere un suo stack.
La concorrenza si studia in particolare in sistemi operativi in quanto un sistema operativo multitasking è un sistema concorrente.
Concorrenza di processi in architetture SMP (Symmetric multiprocessor system) e non. (RD: non mi pare di aver spiegato cosa sia l'SMP) 
Simulazione del fenomeno della '''race condition'''. Si ha '''race condition''' quando un programma concorrente può puo' produrre diversi risultati se eseguito piu' volte per colpa della diversa evoluzione temporale delle elaborazioni. 
Per risolvere questo dovremmo raggruppare le istruzioni in ''sezioni critiche'' (sequenze inscindibili di istruzioni che devono essere eseguite come se fossero atomiche, tutta la sequenza o niente).
* '''Architettura a livelli e virtualizzazione'''
Dato un A e un A’ e riusciamo a usare A’ come A, allora A’ lo possiamo chiamare A virtuale.
L'idea che alla base delle macchine virtuali è di creare un interprete di un ISA differente o uguale a quello del sistema in modo da virtualizzare una reale macchina hardware e quindi poterla usare per gli stessi scopi di una macchina reale. E' quindi possibile, per esempio, installare sistemi operativi su hardware virtuale. 
L'insieme dei componenti hardware virtuali e il software installato su di questi prende il nome di ''macchina virtuale''.
Uno dei principali vantaggi, oggi molto utilizzato in ambito cloud, è quello di poter suddividere facilmente risorse hardware fisiche, per esempio spazio su disco e potenza di elaborazione, tra macchine virtuali differenti.
* '''Laboratorio di cross-compiling'''
Nel ultima parte della lezione abbiamo fatto un esperimento sulla portabilità dei compilatori. 
Abbiamo a disposizione un linguaggio ad alto livello che chiameremo L, due interpreti hw0 e hw1 per linguaggi a basso livello che chiameremo lhw0 e lhw1 e infine due compilatori L->lhw0 uno scritto in python e l'altro in L. 
Se compiliamo con il compilatore scritto in python (abbiamo un interprete python installato sulla macchina che stiamo utilizzando) il compilatore scritto in L otteniamo un compilatore scritto in lhw0 L->lhw0. 
Se ora modifichiamo il compilatore scritto in L L->lhw0 in modo che crei codice per hw1 (basta modificare gli indici numerici delle istruzioni) otteniamo un compilatore in L L->lhw1. Se lo compiliamo con il compilatore L->lhw0 otteniamo un ''cross-compiler'' scritto in lhw0 L->lhw1, cioè un compilatore che crea codice eseguibile su una macchina diversa da quella attuale. 
Se ora utilizziamo il cross compiler L->lhw1 per compilare il compilatore scritto in L L->hw1 otteniamo invece un compilatore che può essere eseguito su hw1. 
A questo punto su hw1 potremmo utilizzare l'ultimo compilatore creato per compilare sempre il compilatore scritto in L L->hw1 ma vedremo che otterremo sempre lo stesso file perché avremo raggiunto il limite.
 
Il materiale per poter replicare l'esperimento sulla portabilità dei compilatori è [http://www.cs.unibo.it/~renzo/so/tools/portability3.tgz qui].
[[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 13:42, 8 October 2016 (CEST)

== Lezione del 11 ottobre 2016 ==
*'''C'''
<syntaxhighlight lang=C>
#include <stdio.h>

void dump (void* f, size_t len){ //size_t is the sizeof() return type
unsigned char *s = f;
size_t i;
for (i = 0; i < len; i++)
printf("%02x ",s[i]); //%02x means print at least 2 digits and add 0's if there are less
printf("\n");
}

int main(){

int v[] = {1, 2, 3, 4}; //v is (int*) 0x32ef...
v[2] = 42; //*((int*) 0x32ef) + 2 = 42, moves the address by 2 "positions", aka 4+4 bytes
v[2] = 0x33;//(int*) 0x32ef.. = 0x33 (i.e.) 4 = 42

char s[] = "ciao";
int t[] = {0x63, 0x69, 0x61, 0x6f, 0x00}; //ciao in ASCII hex. if int OUT:'c'. if char OUT:"ciao"
char u[] = {99, 105,97, 111, 0 }; //ciao in ASCII dec. OUT:"ciao"

char *q = "ciao";
char *w = "mare";

printf("%s\n", s);
printf("%s\n", t);
printf("%s\n", u);

dump(s, sizeof(s));
dump(t, sizeof(t));
dump(q, sizeof(*q)); //*q size is 1B (it points to 1 char). OUT: 63('c')
dump(q, sizeof(q)); //q size is 8B. OUT: 5B of "ciao" + 3B of contiguous string "mare"
}
</syntaxhighlight>

OUTPUT:
<pre>
ciao
c
ciao
63 69 61 6f 00
63 00 00 00 69 00 00 00 61 00 00 00 6f 00 00 00 00 00 00 00 //int are 4B, char 1B, so we have empty bytes.
Little endian pattern is evident. %s allow to print untill the first null, so printf prints just 'c' with int declaration of t[]
63
63 69 61 6f 00 6d 61 72 // 6d = m, 61 = a, 72 = r.
</pre>

* '''Assioma di finite progress.'''
"Tutto è vero purchè ogni statement abbia durata sconosciuta, ma finita"
* '''Modalità di concorrenza.'''
1- Inconsapevolmente concorrenti: ogni processo elabora ciò per cui è stato creato. Il kernel si occupa di coordinazione e comunicazione.

2- Indirettamente concorrenti: processi che accedono a file condivisi.

3- Consapevolmente concorrenti: il programma ha diversi processi in esecuzione.
*''' Convenzioni usate nel corso (e negli esami) relative alle istruzioni atomiche'''
Le istruzioni atomiche vengono compiute in modo indivisibile, garantendo che l'azione non interferisca con altri processi durante la sua esecuzione.
Vengono rappresentate nel seguente modo:
<pre>
<istruzione atomica>
</pre>
Anche gli statement sono istruzioni atomiche(escluso il caso long long).
*''' Proprieta' di Safety e Liveness'''
-Safety: se il programma evolve, evolve bene(S)

"''Something good'' happens"

-Liveness: il programma va avanti(L)

"''Something eventually'' happens"

* '''Problema del consenso.'''
Il problema è così definito: ci sono n processi, ognuno propone un valore. Al termine tutti i processi devono accordarsi su di 1 dei valori proposti.Il suddetto problema è risolvibile se e solo se vengono rispettate le seguenti proprietà (2 di Safety + 1 di Liveness)

Proprietà:

S(1)- Tutti i processi devono ritornare lo stesso valore

S(2)- Ogni processo corretto decide uno tra i valori proposti

L(1)- Ogni processo corretto deve dare una risposta

w/o S(1): f(x) = x

w/o S(2): f(x) = 42

w/o L(1): f(x) = while(1)

*w/o = without

* '''Problemi delle elaborazioni concorrenti. Prima definizione (non formale) di Deadlock e Starvation'''
Introduzione alla notazione per la rappresentazione dei processi concorrenti

ESEMPIO 1.0

process p {
...
...
}

process q {
...
...
}

Due processi eseguiti in concorrenza.

...
cobegin
...
//
...
//
...
coend

cobegin e coend indicano la sezione di codice con le istruzioni (rappresentate da "..." e separate da "//")che verranno eseguite in concorrenza.

ESEMPIO 1.1 - Merge sort
cobegin
sort(v[1 : N])
//
sort(v[N : N])
//
merge(v[1 : N]), v[N : M])
coend

Se isoliamo le istruzioni senza considerare cobegin e coend, lo pseudocodice è corretto.
Se consideriamo anche cobegin e coend il programma esegue la funzione di merge() in concorrenza con le due chiamate a sort(), utilizzando risorse in comune e pertanto cercando di ordinare elementi non ancora ordinati nelle due metà dell'array.
Se spostiamo l'invocazione di merge al di fuori della sezione cobegin ... coend, lo pseudocodice (vedi in basso) è corretto.

cobegin
sort(v[1 : N])
//
sort(v[N : N])
coend
merge(v[1 : N]), v[N : M])

In particolare nella programmazione concorrente si devono affrontare due problemi che riguardano la liveness, parliamo di deadlock e starvation.

'''DEADLOCK''': uno o più processi non possono continuare l'esecuzione perchè ognuno di essi è in attesa che gli altri facciano qualcosa

ESEMPIO 1.2

process p {
while 1:
prendi a
prendi b
calcola f(a,b)
lascia a
lascia b
}

process q {
while 1:
prendi a
prendi b
calcola f(a,b)
lascia a
lascia b
}

Supponiamo di invertire l'ordine di prendi a e prendi b nel processo p. Dopo che entrambi i processi eseguono la prima istruzione lo scenario che si sviluppa è il seguente: al processo p serve la risorsa a, presa dal processo q, al quale servirebbe la risorsa b, presa dal processo p. I processi aspettano a vicenda che uno rilasci la risorsa che possiede l'altro. Risorsa necessaria ad entrambi i processi per eseguire l'istruzione (f(a,b)) che le richiederebbe entrambe. I processi sono deadlocked.

'''STARVATION''': quando un processo attende una risorsa indefinitamente, e questa non gli viene mai allocata

ESEMPIO 1.3
process p {
while 1:
prendi a
calcola f(a)
lascia a
}

process q {
while 1:
prendi a
calcola f(a)
lascia a
}

Supponiamo che i processi per realizzare "prendi a" verifichino la disponibilità di a tramite polling (provando ripetutamente se a è libero). Il processo q può essere sfortunato e non riuscire mai ad avere accesso ad a (tutte le volte che cerca di "prenderlo" lo troverà impegnato da p). Il processo q è in starvation.

ESEMPIO 1.4
"Supponiamo di avere tre processi (P1, P2, P3) i quali richiedono periodicamente accesso alla risorsa R. Consideriamo la situazione nella quale P1 è in possesso della risorsa, e sia P2 che P3 attendono per quella risorsa. Quando P1 esce dalla sua sezione critica, a P2 o P3 dovrebbe essere permesso l'accesso a R. Assumiamo che il SO garantisca l'accesso a P3 e che P1 richieda nuovamente la risorsa prima che P3 termini la sua sezione critica. Se il SO dovesse garantire l'accesso a P1 dopo che P3 abbia finito, e successivamente dovesse garantire alternativamente a P1 e P3 l'accesso alla risorsa, allora P2 potrebbe vedersi indefinitamente negato l'accesso alla risorsa, sebbene non vi sia una situazione di deadlock" (Stallings W.(2015). ''Operating System: internals and design principles''. (8th ed). Pearson)

'''Problema: posso creare sezioni critiche, tramite la programmazione, senza aiuti hardware?'''

ESEMPIO

process p
/*enter_cs*/
A = A + 1
/*exit_cs*/

process q
/*enter_cs*/
A = A - 1
/*exit_cs*/

'''Le 4 proprietà della critical section(CS)'''

SAFETY(1): una operazione all'interno della CS

ESEMPIO
process p
while 1:
/*enter_cs*/
A = A + 1
/*exit_cs*/
... <--- process q deve poter "entrare" qui

LIVENESS(1): no deadlock

LIVENESS(2): no starvation

LIVENESS(3): no useless wait

''Dekker(1st attempt) //KEY: turno''

turn = p //var globale condivisa

process p{
while (turn != p)
;
/*A = A + 1*/
turn = q
...
}

process q{
while(turn != q)
;
/*A = A - 1*/
turn = p
...
}

Non rispetta la proprietà di liveness(3), infatti uno dei due processi può dover attendere a lungo il suo turno eseguendo ciclicamente l'empty statement all'interno
del corpo del while. Questa situazione può verificarsi se l'altro processo fallisce dentro o fuori la sua CS (in questo caso l'attesa è infinita). Inoltre visto che i processi si alternano strettamente nell'utilizzo della loro critical section, il ritmo di esecuzione è dettato dal processo più lento dei due.

''Dekker(2nd attempt) //KEY: flag, ma senza turno''

inp = false

inq = false

process p{
while 1:
while(inq)
;
inp = true
/*A = A + 1*/
inp = false
...
}

process q{
while 1:
while(inp)
;
inq = true
/*A = A - 1*/
inq = false
...
}

In questo caso se uno dei processi fallisce fuori dalla CS (dopo aver settato il flag a false) l'altro processo non viene bloccato. Se invece un processo fallisce nella sua CS oppure dopo aver settato il flag a true allora l'altro processo resta bloccato indefinitamente. Non è garantita inoltre la mutua esclusione in quanto entrambi potrebbero essere al contempo nelle loro rispettive CS, ad esempio:

p valuta la condizione del while e trova inq a false

q valuta la condizione del while e trova inp a false

p assegna true a inp ed entra nella sua CS

q assegna true a inq ed entra nella sua CS

....entrambi sono nella rispettiva CS --> no liveness(1)

''Dekker(3nd attempt) //KEY: come 2nd ma con due istruzioni scambiate di ordine''

process p{
while 1:
inp = true
while(inq)
;
/*A = A + 1*/
inp = false
...
}

process q{
while 1:
inq = true
while(inp)
;
/*A = A - 1*/
inq = false
...
}

Scambiando l'ordine di due istruzioni vi è la mutua esclusione, tuttavia se entrambi i processi assegnano true al loro rispettivo flag, prima di valutare la condizione
del while, entrambi resteranno all'interno del while in attesa che l'altro processo "esca dalla CS" (non vi è mai entrato) --> deadlock

''Dekker(4nd attempt) //KEY: flag + delay''

process p{
while 1:
inp = true
while(inq){
inp = false; < delay >; inp = true;
}
/*A = A + 1*/
inp = false
...
}

process q{
while 1:
inq = true
while(inp){
inq = false; < delay >; inq = true;
}
/*A = A - 1*/
inq = false
...
}

In questo caso il settare il proprio flag a true è indice del desiderio di entrare nella propria CS. Vi è ancora mutua esclusione. Se però dovesse verificarsi una sequenza del tipo:

p imposta flag inp a true

q imposta falg inq a true

p valuta la condizione del while

q valuta la condizione del while

p imposta flag inp a false

q imposta flag inq a false

p imposta flag inp a true

q imposta flag inq a true

allora c'è la possibilità che si ripeta all'infinito (entrambi i processi potrebbero rimanere nel while). Essendo però una condizione che dipende dalla velocità relativa dei due processi, esiseranno delle situazioni nelle quali uno dei due processi potrà entrare, così come vi saranno delle situazioni nelle quali nessun processo avrà accesso alla propria CS --> livelock

'''Dekker...finally //KEY: flag + turni ("cambio delay con turno)'''

needp = false

needq = false

turn = p

process p{
while 1:
needp = true
while (needq) {
needp = false
while(turn == q)
;
needp = true
}
/*A = A + 1*/
needp = false
turn = q
...
}

process q{
while 1:
needq = true
while(needp) {
needq = false;
while(turn == p)
;
needq = true
}
/*A = A - 1*/
needq = false
turn = p
...
}

In questo caso il processo che vuole entrare nella sua CS ne manifesta il bisogno settando need a true. Se entrambi i processi entrano nel corpo del while il tie-break è espletato dal while la cui condizione è un turn che sarà uguale soltanto ad uno dei due processi (in questo caso turn è inizializzata a p), e dunque non si verificherànno situazioni di deadlock o livelock.
*'''Proprietà della sezione critica'''
Mutua esclusione 
Assenza di deadlock 
Assenza di starvation 
Assenza di delay non necessari

*'''La test&set'''
E' un istruzione atomica per impostare il valore di una variabile a 1 (lock) ma ritornare il vecchio valore. Questa istruzione può essere utilizzata per gestire sezioni critiche. 
Il valore ritornato dalla test and set viene comparato a 1, se è uguale si aspetta altrimenti si procede. 
In questo modo il primo processo che cercherà di entrare nella sezione critica ci riuscirà e imposterà il lock a 1, gli altri processi si troveranno il lock a 1 e dovranno aspettare. Quando il primo processo avrà finito ripristinerà il vecchio valore di lock e permetterà a uno degli altri processi di eseguire la test and set e di entrare nella sezione critica.
----
Altri argomenti trattati che non sono stati qui riportati in forma di appunti:
Gestione algoritmica della critical section.
Algoritmo di Dekker.
Gestione architetturale della critical section.

[[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 10:35, 17 October 2016 (CEST)

== Lezione del 14 ottobre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7UlJadTRVbzhWRFE 14\10\16]
* Sistemi Operativi per elaboratori multiprocessore SMP/non SMP
* Macchine di von Neumann (e di Harvard).
* Il bus.
* Interrupt e Trap
* Gestione degli interrupt
* Mascheramento degli interrupt
* Interrupt Nidificati
* DMA
* Device a carattere e device a blocchi
* System call come trap.
* La gerarchia delle memorie
* cache

== Lezione del 18 ottobre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7eVlFdWR0cUkxd2M 18/10/16]

Argomenti trattati:
*'''Implementazione in C della Test&Set, degli Algoritmi di Dekker e Peterson.'''
Codice sorgente disponibile [[Dekker,_Peterson_e_Test%26Set_in_C|qui]].
*'''Definizione di Semaforo.'''
Un semaforo è una variabile intera che può essere modificata solo da 2 operazioni atomiche: P(Proberen) e V(Verhogen). 
P aspetta che il valore sia minore o uguale a zero. Quando lo diventa decrementa il valore. 
S incrementa il valore. 
*'''Invariante del Semaforo.'''
Il numero di Proberen deve essere minore o uguale al numero di Verhogen più il valore d'inizializzazione del semaforo. 
In questo modo si può gestire per esempio l'allocazione di risorse. Il semaforo viene inizializzato al numero di risorse e ogni volta che un processo ha bisogno della risorsa esegue un proberen, quindi decrementa il valore se la risorsa è disponibile. Quando un processo rilascia la risorsa esegue un verhogen.
*'''Esempio: implementazione di sezione critica e di semplice sincronizzazione con semafori.'''

== Lezione del 21 ottobre 2016 ==
*'''Make'''
Make è un sistema per la compilazione intelligente dei programmi. 
Permette invece di compilare tutto il programma tutte le volte di compilarne solo una parte, solo quella che è stata modificata.
Per capirne il funzionamento è utile un parallelismo con le ricette di cucina. Si specificano dei target che sono gli obbiettivi della ricetta.Per fare una ricetta servono degli ingredienti e magari quegli ingredienti hanno a loro volta delle ricette. Make allo stesso modo definisce dei target che possono avere come dipendenze altri target. 
Nel installazione del programma il programma ./configure cerca nel sistema se le librerie da cui è dipendente il programma sono presenti. 
*'''Git'''
Git è un sistema di versioning, serve a tener traccia delle modifiche apportante a un progetto nel tempo. E' utile per collaborare a un progetto condiviso. 
Possibilità per ogni membro del repository di lavorare in maniera indipendente e poi aggiornare il progetto comune. 
Ce ne sono stati tanti di sistemi di versioning tipo SVN, Mercurial ma attualmente Git è il più utilizzato. 
Git non serve solo per scrivere programmi ma per esempio anche libri, in modo collaborativo. 
Git è completamente distribuito, non esiste in un repository una copia principale e delle copie secondarie ma ogni copia può essere principale. 
Per iniziare un repository git si utilizza il comando ''git init''. 
Per aggiungere un file al repository si utilizza il comando ''git add''. 
Ma ad ogni singola modifica git non aggiorna automaticamente il repository ma è l'utente che tramite il comando git commit indica che una certa versione del progetto deve essere salvata. 
Il comando ''git log'' serve a visualizzare la storia del repository. 
Il comando ''git diff'' serve a vedere la differenza tra ciò che è nel repository e le modifiche di cui non si è ancora fatto il commit. 
Dopo aver dato il comando add si dice che i file sono 'on stage' prima del commit. 
Il comando ''git checkout'' serve a spostarsi nella storia del repository. 
Il comando ''git clone'' serve a copiare un repository remoto. 
Il comando ''git push'' serve a inviare le modifiche al repository remoto mentre il comando ''git pull'' serve a ricevere le modifiche più aggiornate dal repository remoto. 
Il ''merge'' è il processo in cui uno degli utenti che crea un conflitto deve "a mano" scegliere quali parti dei due commit in conflitto vuole tenere. 
Git è utile per trovare i bug che non erano presenti in versioni precedenti del progetto. Si può tornare alla versione precedente stabile e avanzare nella storia fino a trovare una versione instabile. A questo punto è probabile che l'origine del bug sia nelle modifiche che hanno creato questa versione instabile. 
Github è una piattaforma di repository dove possono essere mantenuti dei progetti gratuitamente se sono con licenza libera. 
In una directory in cui è presente un repository git e sempre la presente la cartella ''.git'' dove il sistema di versioning mantiene il database della storia. 

== Lezione del 25 ottobre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7WjZJMm11cjhuQXc 25/10/16]

Argomenti trattati:
* '''Semafori fair'''
Un semaforo è "fair" quando tende a non sbloccare dallo stato di attesa sempre lo stesso processo ma cerca di distribuire la possibilità di esecuzione a più processi.
* '''Problemi classici della concorrenza risolti con semafori'''
** '''Produttore/consumatore'''
::Due processi: produttore e consumatore. Il produttore genera continuamente dei valori e il consumatore continuamente li legge. Il consumatore deve leggere i valori nello stesso ordine in cui il produttore li genera. 
::Un meccanismo di sincronizzazione e richiesto perchè sorgono immediatamente due problemi:
::* Produttore troppo veloce: il consumatore non fa in tempo a consumare il valore e c'è la possibilità che i valori non ancora letti vengano sovrascritti.
::* Consumatore troppo veloce: possibilità che il consumatore legga un valore che ha già letto perchè il produttore non ha fatto in tempo a produrne uno nuovo.
::Per risolvere il problema utilizziamo due semafori: empty e full. 
::Il produttore aspetta che il segnale del semaforo empty (Proberen), scrive il valore e dà segnale sul semaforo full (Verhogen). 
::Il consumatore aspetta il segnale del semaforo full (Proberen), legge il valore e dà segnale sul semaforo empty (Verhogen). 
:* '''Buffer-limitato'''
::Simile al problema produttore/consumatore ma qui lo scambio avviene tramite un buffer limitato. 
::In questo modo nel caso di rallentamento temporaneo del consumer il producer non deve aspettare ma può produrre più unità e viceversa nel caso di rallentamento del producer, se il buffer ha più di un elemento, il consumer può utilizzare il tempo in attesa del producer per consumare più dati. 
::Nel caso il buffer sia completamente pieno/vuoto rimangono comunque i problemi di sincronizzazione tipici del problema: il producer non deve sovrascrivere dei valori che il consumer non ha ancora letto e il consumer non deve leggere più volte lo stesso valore se il producer non è stato abbastanza veloce da cambiarlo. 
::Come soluzione al problema si può utilizzare un coda circolare. Il produttore esegue una enqueue e il consumatore una dequeue. 
::Il problema può essere generalizzato facilmente a produttori/consumatori multipli ma in questo caso dobbiamo creare un semaforo per rendere atomiche la enqueue e la dequeue altrimenti incorriamo in una race condition nel accesso alla coda.

== Lezione del 28 ottobre 2016 ==

'''Implementazione dei semafori''' 
Un processo che esegue una Proberen in teoria dovrebbe aspettare continuando a controllare se può entrare nella sezione critica. Questo meccanismo si chiama "busy waiting" e consuma molte istruzioni della CPU. 
Il busy waiting è diverso dal polling in quando il polling prevede di eseguire altre azioni mentre si aspetta tra un tentativo e l'altro. 
Di solito si utilizza il busy waiting solo quando il tempo di lock di un processo è molto breve. Questo perchè anche se esoso di risorse del processore il busy waiting non comporta un context switch, cioè salvare tutto lo stato del processo in memoria, e quindi permette di risparmiare memoria.
Se invece il tempo di lock è più lungo allora è preferibile utilizzare un context-switch dove il processo si blocca da solo e chiama un processo di blocking che lo mette in una coda di attesa associata al semaforo che sta aspettando. Il controllo passa poi allo scheduler della CPU che seleziona un altro processo da eseguire.
Le primitive suspend and wakeup indicano rispettivamente lo spostamento di un processo nella/dalla coda dei processi ready.
* nei kernel monoprocessore
: Implementazione dei semafori tramite mutex che possono essere a loro volta implementate con un sistema di mascheramento degli interrupt.
* nei kernel multiprocessore
: Utilizzo di soluzioni hardware come test and set. Sono soluzioni che utilizzano il busy waiting ma in questo caso solo per rendere atomico le operazioni del semaforo, che sono poche istruzioni.
Certe implementazioni dei semafori potrebbero permettere di far andare il valore in negativo. Questo serve per misurare il numero dei processi in attesa di quel semaforo. 
'''Il problema della cena dei filosofi''': 
5 filosofi passano la loro vita pensando e mangiando. Condividono un tavolo circolare con 5 sedie e ogni sedia appartiene a un solo filosofo. Alla sinistra e alla destra di ogni piatto c'è una bacchetta per un totale di 5 bacchette. La bacchetta destra che un filosofo usa per mangiare viene quindi utilizzata come bacchetta sinistra dal filosofo alla sua destra e simmetricamente è uguale per il filosofo che siede a sinistra. 
Ogni tanto un filosofo smette di pensare e cerca di prendere le rispettive bacchette, se ci riesce può mangiare e poi rilasciare le bacchette. 
Questo problema è un modello di problema ad accesso a ''insiemi'' di risorse. Mentre nel produttore/consumatore e buffer limitato gli attori in gioco avevano la necessità di avere l'accesso esclusivo a una sola risorsa in questo problema è richiesto l'accesso a insiemi di risorse (le bacchette) le cui parti possono essere desiderate da altri richiedenti.
* soluzione con contesa sulle posate e casi di deadlock
:Poniamo un semaforo per ogni bacchetta. Può succedere però, se nel implementazione i filosofi "prendono in mano" prima la bacchetta destra e poi quella sinistra, che tutti prendono in mano contemporaneamente la bacchetta destra e rimangono in un'attesa infinita della bacchetta sinistra che non gli verrà mai rilasciata perché anche il rispettivo filosofo alla propria sinistra è in attesa. Questo è un caso di deadlock. 
:Una soluzione può essere quella di imporre che un filosofo sia "mancino" cioè prenda prima la bacchetta a sinistra e poi la destra. 
* soluzione con acquisizione atomica di entrambe le posate, casi di starvation
:Un'altra soluzione è quella di rendere atomico l'acquisizione di entrambe le posate. 
:Può succede che 4 filosofi compiano una "congiura", cioè siano d'accordo a non lasciar risorse a un quinto filosofo. Questo è un caso di starvation e non è irreale in quando i 4 filosofi potrebbero essere processi malevoli che siano stati programmati di proposito per questo.
'''System Call''':
* POSIX.
:Il POSIX è uno standard (IEEE 1003) che definisce le signature delle system call. Un sistema operativo deve rispettare il POSIX per essere definito "Unix-like". 
:Di solito i parametri delle system call sono pensati per essere contenuti in un registro. Quasi sempre le system call ritornano un intero: 0 se la procedura è stata eseguita correttamente, -1 se c'è un errore. Quando una system call ritorna -1 la variabile "globale" errno (error number) contiene il codice di errore. La variabile errno non è realmente globale perché ne esiste una per ogni processo. 
:Unix è un sistema operativo file-system centrico quindi quando facciamo input/output anche da periferiche come stampanti e lettori CD usiamo le system call per la scrittura/lettura dei file. 
:Un catalogo delle system call principali può essere trovato [[Il ''catalogo'' delle System Call | qui]].
* fork/exec
:fork e exec sono system call importanti e servono per creare un nuovo processo: 
:fork: genera un processo clone di quello che ha chiamato fork. 
:exec: "cambia" il codice eseguito dal processo corrente. 
:Quindi per "aprire un nuovo programma" si utilizza una fork seguita da un exec.

== Lezione del 4 novembre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7blhMT0tSNDRGSUU 4/11/16]

* '''Problema della Cena dei filosofi'''. Soluzione con acquisizione atomica delle bacchette (con starvation)
* '''Tecnica del passaggio del testimone''' (Passing the Baton).

: Non uscire dalla mutua esclusione se c'è qualcun altro che vuole entrarci e semplicemente fare in modo che lui l'acquisisca. La mutua esclusione termina solo se non c'è nessuno che più la richiede.

ESEMPIO IMPLEMENAZIONE BATON
<syntaxhighlight lang=C>
void baton(int i) {
int j;
for (j=1; j<5; j++) {
if(philo_status[(i+j)%5] == 'W' && philo_status[(i+j+1)%5] != 'E' && philo_status[(i+j+4)%5] != 'E') {
semaphore_V(philowait[(i+j)%5]);
return;
}
}
semaphore_V(mutex);
}
</syntaxhighlight>
* '''Cena dei filosofi, acquisizione atomica delle bacchette con passaggio del testimone'''.
* '''Implementazione della congiura dei filosofi'''

* '''Le system call di gestione file (open, read, write, close, lseek)'''
Quando lavoriamo con dei file dobbiamo sempre specificare se vogliamo solo leggerli oppure anche scrivere, magari in append mode. Ci sono quindi varie modalità con cui possiamo interagire con i file. 
Un utente potrebbe essere autorizzato a gestire il file in certe modalità oppure no. 
Il descrittore di un file è un intero. 
Le system call, a differenza delle chiamate di funzioni di libreria, non sono bufferizzate.

ESEMPIO

Se si decommenta printf stampa 2 volte hello world perchè la stringa resta nel buffer.

Se si decommenta write stampa 1 volta hello world.

Per vedere le chiamate di sistema effettuate in fase di esecuzione, compilare il codice sorgente e poi utilizzare strace -f "eseguibile".
<syntaxhighlight lang=C>
#include<stdio.h>
#include<unistd.h>

int main(int argc, char* argv[]){
//printf("hello world"); //if you ends the strings with \n is like to "fflushing" the buffer
//write(1, "hello world", 11); // 1 and 11 are file descriptors
switch(fork()) {
case 0: //child
break;
default: //parent
wait(NULL);
break;
case -1: //error
break;
}
printf("\n");
return 0;
}
</syntaxhighlight>

Copia il file passato come primo argomento (argv[1]) nel file passato come secondo argomento (argv[2]), se quest'ultimo non esiste, allora lo crea.
<syntaxhighlight lang=C>
#include<stdio.h>
#define BUFSIZE 2048
char buffer[BUFSIZE];
int main(int argc, char *argv[]){
int fdin = open(argv[1], O_RDONLY);
int fdout = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, 0666); //0666 is the umask used to modify the permissions of new files

int n;
while((n = read(fdin, buffer, BUFSIZE)) > 0)
write(fdout, buffer, n);

close(fdin);
close(fdout);
return 0;
}
</syntaxhighlight>

'''umask''' 
Con la open possiamo usare dei permessi al massimo per quelli garantiti dal umask. 
Un numero composto da quattro cifre ottali. Controlla la maschera di creazione dei file. I bit di permesso contenuti nella maschera NON vengono settati nel nuovo file creato. Corrisponde all'opereazione:

R:(D &(~M))

Può essere vista come una sottrazione, i bit accesi nella umask vengono spenti nel file creato.

e.g. se i permessi di default corrispondono a 0666(D) e la maschera corrisponde a 0022(M), R è uguale a 0666-0022 = 0644. Infatti

0022 = |000|000|010|010|
~0022 = |111|111|101|101|(7755)
0666 = |000|110|110|110|
~0022 & 0666 = |000|110|100|100|(0644)

Tabella significato cifre umask

OTTALE BINARIO SIGNIFICATO
0 000 Nessun permesso
1 001 Solo esecuzione
2 010 Solo scrittura
3 011 Scrittura ed esecuzione
4 100 Solo lettura
5 101 Lettura ed esecuzione
6 110 Lettura e scrittura
7 111 Lettura, scrittura ed esecuzione

I permessi sono rappresentati in simboli come segue:

r: read
w: write
x: execute

'''umask - S''' da shell per visualizzare la umask attuale con rappresentazione simbolica

'''ls -l "nomefile"''' da shell per visualizzare i permessi del file in notazione simbolica: '-' seguito da 3 triple che indicano i permessi di accesso per '''ugo''', ovvero, rispettivamente, per user, per group, per other.

ESEMPIO
-rw-r--r--

* '''File aperti durante fork/exec'''https://www.kernel.org/

I file aperti vengono ereditati dai processi figli.
Processo padre e processo figlio condividono lo stesso offset nei file comuni. In questo modo si evita di sovrascriversi a vicenda. Ogni volta che il padre o il figlio scrivono sul file aggiornano l'offset comune.In questo modo se l'altro processo vuole anche lui scrivere in quel file partirà dal offset aggiornato e non sovrascriverà i dati scritti dal altro processo. 

* '''La system call dup e la ridirezione'''
E' possibile fare in modo che più file descriptor siano associati a un unico file (per la precisione a un unica file table, che serve per gestire un file). 
La system call dup permette di fare ciò. Ritorna un nuovo file descriptor che punta a una file table già esistente. 
Possiamo quindi "ridirezionare" l'output o l'input di un processo figlio modificando i file descriptor prima di creare il processo figlio. Per esempio possiamo modificare un file descriptor che puntava a un normale file in modo che punti a un file di standard output e quindi anche se al processo figlio sembrerà di scrivere in un normale file starà scrivendo nel terminale.

ESEMPIO

<syntaxhighlight lang=C>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>
#include<stdio.h>
#include<unistd.h>

int main(int argc, char * argv[]){
int fdout;
if(argc > 1);
fdout = open (argv[1], O_WRONLY | O_CREAT | O_TRUNC, 0666);
switch(fork()) {
case 0: //child
dup2(fdout, 1); // duplica descrittore file, posso ridirezionare l'output. E' come fare '>' dalla shell
execlp(”ls”, “-l”, 0);
close(fdout);
break;
default: // parent
wait(NULL);
break;
case -1: // error
break;
}
printf(“\n”);
return 0;
}
</syntaxhighlight>

== Lezione del 8 novembre 2016 ==
'''Codice per la congiura dei filosofi'''
<syntaxhighlight lang=C>
#include <stdio.h>
#include <stdint.h>
#include <pthread.h>
#include "semaphore.h"

semaphore philowait[5];
semaphore mutex;
semaphore cospsem;
char philo_status[]="TTTTT";

void baton(int i){
int j = 0;
//iterate through remaining philosophers
for(j = 1; j < 5;j++){
//if there's any waiting philosopher, and no other philosophers(on his left and right side) are eating
if(philo_status[(i+j)%5]=='W' && philo_status[(i+j+1)%5]!= 'E' && philo_status[(i+j+4)%5]!='E'){
semaphore_V(philowait[(i+j)%5]);
return;
}
}
semaphore_V(mutex);
}

void ok2eat(int i){
semaphore_P(mutex);
philo_status[i]='W';
if(philo_status[(i+1)%5] == 'E' || philo_status[(i+4)%5] == 'E'){
semaphore_V(mutex);
semaphore_P(philowait[i]); //wait for baton
}
philo_status[i] = 'E';
printf("philo eating: %d |%s|\n",i,philo_status);
baton(i);
}

void ok2think(int i){
semaphore_P(mutex);
philo_status[i] = 'T';
printf("philo thinking: %d |%s|\n",i,philo_status);
baton(i);
}

void conspiracy_in(){
static int first_time = 1; //this variable's value is preserved between calls to this function
semaphore_P(mutex);
if(first_time){
//first conspirator entering here will act like nothing happened
first_time = 0;
}
else{
//conspire
semaphore_V(cospsem);
}
semaphore_V(mutex);
}

void conspiracy_out(){
semaphore_P(cospsem);
}

void *philo(void *arg) {
int i = (uintptr_t)arg;
while (1) {
//thinking/still thinking
usleep(random() % 200000);
ok2eat(i);
//eating

//conspirators need to be synchronized to conspire
if(i==1 || i==3) conspiracy_in();
usleep(random() % 200000);
if(i==1 || i==3) conspiracy_out();
ok2think(i);
//thinking again
}
}

int main(int argc, char *argv[]) {
int i;
pthread_t philo_t[5];
srandom(time(NULL));
mutex = semaphore_create(1);
cospsem = semaphore_create(0);
for (i=0; i<5; i++)
philowait[i]=semaphore_create(0);
for (i=0; i<5; i++)
pthread_create(&philo_t[i], NULL, philo, (void *)(uintptr_t) i);
for (i=0; i<5; i++)
pthread_join(philo_t[i], NULL);
}
</syntaxhighlight>

* '''Problema dei lettori e scrittori'''
:Spesso quando gestiamo la concorrenza all’accesso a strutture dati separiamo i ruoli di solo lettori con anche quello di scrittori (che per fare ciò possono dover anche leggere).
:Mentre che per i lettori non c’è un limite a quanti contemporaneamente possono avere accesso alle informazioni, gli scrittori devono avere accesso esclusivo alla struttura dati.
:Questo perché incorriamo in una race-condition solo quando modifichiamo la struttura dati.
:Dare precedenza di accesso a una categoria o all’altra porta starvation nella categoria con meno priorità.
:Una soluzione che abbiamo dato è quella di dare esclusività ai ruoli a turno:
:dopo che uno scrittore ha finito di scrivere garantisce l’accesso prima a tutti i lettori in attesa e se non sono presenti agli scrittori in attesa. Per i lettori è il contrario: dopo che l’ultimo lettore ha finito di leggere garantisce l’accesso a uno dei possibili scrittori in attesa e se non ce ne sono ai lettori.
:La soluzione in C al problema lettori e scrittori può essere trovata [[Zibaldone|qui]].
* '''Semafori Binari(Introduzione)'''
: Un semaforo binario è un semaforo ordinario che rispetta la seguente invariante: '''nP<=nV+Init<=nP+1''', ovvero è un semaforo che può assumere solo valori 0 o 1.
: Si può dimostrare che i semafori ordinari sono espressivi tanto quanto quelli binari(e viceversa) fornendo una implementazione di semafori binari tramite i semafori ordinari e viceversa una implementazione di semafori ordinari tramite semafori binari. (l'invariante dei semafori binari si può anche scrivere '''0 <= nV + Init - nP <= 1''' dove '''nV + Init - nP''' rappresenta proprio il valore del semaforo).

== Lezione del 11 novembre 2016 ==
* '''Valore di ritorno di un processo'''
:Un processo ritorna un valore che è un numero intero. 
:Questo può essere deciso come valore di ritorno del main, oppure con la funzione ''exit''.
:La system call wait aspetta che lo stato di un processo figlio cambi e quando cambia scrive il nuovo in una variabile. 
:Quando un programma termina il suo valore di ritorno viene salvato nel descrittore del processo. Se il padre non esegue la wait il descrittore del processo figlio non verrà mai eliminato e il processo figlio rimarrà uno "zombie".
:Un esempio del uso si queste system call si può trovare [[2016-17_Programmi_C#Print_child_exit_status|qui]].
* '''Pipe'''
:La system call pipe crea un canale monodirezionale che può essere usato per la comunicazione tra processi. Dimostrazione del uso di pipe si può trovare [[2016-17_Programmi_C#Demonstration_of_the_use_of_pipe_system_call|qui]].
* '''Lo zoo delle exec'''
<syntaxhighlight lang='C'>
int execl(const char *path, const char *arg, ...);
int execlp(const char *file, const char *arg, ...);
int execle(const char *path, const char *arg, ..., char * const envp[]);
int execv(const char *path, char *const argv[]);
int execvp(const char *file, char *const argv[]);
int execvpe(const char *file, char *const argv[],char *const envp[]);
</syntaxhighlight>
Spiegazione dei postfissi:
* l = elenco dei parametri passato tramite parametri a cardinalità variabile (variadic function)
* v = elenco dei parametri passato come array
* p = bisogna specificare il path completo dell'eseguibile
* e = bisogna specificare anche l'enviroment con cui verrà eseguito il programma. L'enviroment è una serie di variabili globali, tra cui il path. Il path è l'elenco dei percorsi dei programmi più usati.
Tutte queste funzioni alla fine sono solo delle interfacce per execve.
* '''Programmazione ad eventi'''
:E' un paradigma di programmazione dove il flusso del programma è determinato dal avverarsi di eventi. Il programmatore specifica il codice (Handlers) che deve essere eseguito al verificarsi di un certo evento. 
:System call che sono utili per far questo sono select,pselect,poll,ppoll,epoll.

== Lezione del 15 novembre 2016 ==
* '''Differenza tra select,poll,pselect,ppoll e epoll'''
:La poll a differenza della select richiede un array di strutture pollfd invece che una bitmask. Permette di specificare precisi eventi per cui stare in ascolto. 
:Le versioni con prefisso "p" implementano anche la gestione dei segnali. 
:L'epoll è linux only. E' moderna (2002) e fornisce un file dove leggere direttamente quali file descriptor sono stati modificati in modo da non dover scorrere tutta la lista.
* '''Dimostrazione della equivalenza di potere espressivo fra semafori e semafori binari.'''
:I semafori implementati per dimostrare l'equivalenza possono essere trovati a [[Esperimenti_con_semafori_e_monitor_in_C | questa pagina]].
* '''Definizione di Monitor.'''
Un monitor è un costrutto ad alto livello per la sincronizzazione pensato ispirandosi alla programmazione ad oggetti. 
E' una classe che incapsula la risorsa condivisa, la rende privata e permette di accedere a questa solo tramite metodi. Questi metodi implementano i meccanismi di sincronizzazione. 
Uno solo processo può essere al interno del monitor e avere accesso ai dati protetti da mutua esclusione. 
E' presente una coda di attesa per l'accesso al monitor. 
Definiamo inoltre delle variabili ''condition''. 
Gli unici metodi che possono essere chiamati su una condition sono wait e signal. Ogni condition ha una propria coda di attesa 
L'operazione wait sospende il chiamante e lo sposta nella coda di attesa della condition.
L'operazione signal risveglia un processo in attesa. Se non c'è nessun processo in attesa all'interno del monitor la signal fa entrare un eventuale processo in attesa di entrare nel monitor. Il chiamante di signal dopo aver risvegliato l'altro possibile processo deve mettersi in attesa per evitare che ci siano due processi in concorrenza al interno del monitor, ma invece di andare nella coda di attesa della condition viene messo in un ''urgent stack'' che ha più priorità rispetto alla coda esterna dei processi in attesa di entrare nel monitor. 
Ricapitolando le strutture dati per un monitor sono una coda esterna per l'accesso al monitor, una coda interna (non accessibile da fuori ma non dentro la mutua esclusione) per ogni variabile condizionale e l'urgent stack. 
* '''Implementazione dei Semafori tramite monitor.'''

== Lezione del 18 novembre 2016 ==
* '''File speciali a blocchi o a caratteri'''
: In Unix molte cose sono rappresentate come file. Per esempio i device come i terminali e le partizioni del disco sono file. Si chiamano ''file speciali'' ma non sono tanto differenti dai file comuni. Utilizzano anche gli stessi sistemi di protezione all'accesso. Si dividono i due categori:
:* File speciali a blocchi: utilizzati maggiormente dai sistemi di storage tipo hard-disk e CD-ROMs. Se per esempio il blocco è di 1024 bytes allora possiamo scrivere e leggere con tale granularità, cioè non potremo mai scrivere soltato 500 bytes ma dovremo scrivere, appunto a "blocchi".
:* File speciali a caratteri: utilizzati maggiormente per dispositivi di input-output tipo mouse,tastiera,terminali ecc.. permettono di lavorare con una granularità di 1 byte ma hanno un accesso sequenziale invece che diretto come i file a blocchi.
:Inoltre nei file speciali l'ampiezza è sostituita da 2 numeri, uno che indica il driver del dispositivo e l'altro le possibili parti del dispositivo, per esempio le partizioni.
* '''System call ioctl'''
: Ioctl serve per controllare dei device. Per esempio permette di fermare la testina di lettura del disco oppure far partire il motore del lettore CD. E' necessaria in quando si è voluto uniformare la lettura e scrittura di stream per tutti i device tramite le system call read/write ma chiaramente ogni dispositivo ha anche le sue diverse necessità e queste vengono soddisfatte da ioctl.
* '''Syscall'''
: Syscall è una funzione di libreria C che serve a chiamare system calls che non hanno una loro interfaccia per il linguaggi C. Per esempio getdents.
* '''System call e funzioni di libreria per directory'''
:Le directories sono sempre file ma si può fare l'accesso solo in lettura, per esempio per ottenere la lista di tutti i file e directory all'interno di quella directory. 
:getdents legge un file directory ed è la system call principale, tutte le funzioni di libreria C tipo opendir,readdir,readdir_r(per multithread) chiamano getdents. 
:Tutte queste funzioni lavorano con una struct dirent che rappresenta una directory entry. 
:Si può usare anche scandir che è reetrant (nessun problema di race condition) e invece di leggere un elemento della directory per volta ritorna direttamente un array di tutti gli element allocato dinamicamente (occorre ricordarsi di deallocare con free tutti gli elementi e l'array stesso).

== Lezione del 22 novembre 2016 ==

Problema dei filosofi a cena risolto con i monitor. Soluzione con le condizioni associate alle "bacchette" e con le condizioni associate ai filosofi.
discussione dei problemi di deadlock e starvation nell'implementazione tramite monitor.

Problema dei lettori e scrittori tramite monitor. Soluzione con privilegio ai lettori, agli scrittori e modifiche necessarie per la soluzione priva di starvation.

== Lezione del 25 novembre 2016 ==
[[Coding Contest]]

== Lezione del 29 novembre 2016 ==
* '''Implementazione dei monitor tramite semafori'''
:Un soluzione simile a quella vista a lezione può essere trovata [[Esperimenti_con_semafori_e_monitor_in_C#Monitor implementati con semafori | qui]].
* '''Introduzione al message passing'''
:E' un altro modo per fare programmazione concorrente alternativo alla memoria condivisa che abbiamo visto fin ora.
:Se i programmi non condividono memoria ma devono sincronizzarsi per lavorare assieme hanno bisogno di scambiarsi messaggi.
:Per l'indirizzamento serve un sistema di naming, come il pid dei processi.
:Due primitive: send e receive. Nella receive come indirizzo da chi ricevere si può mettere una wildcard in modo da riceve da tutti.
:Nella send invece occorre indicare l'identificativo del destinatario (se si ammettesse di poter inserire una wildcard si spedirebbero messaggi in broadcast/multicast. E' una problematica più complessa che viene trattata nei corsi di sistemi distribuiti).
:Lo scambio di messaggi può essere:
:* Sincrono: send bloccante e receive bloccante, senza memoria di supporto.
:* Asincrono: send non bloccante e receive bloccante, con memoria di supporto. I messaggi spediti rimangono in una coda (di ampiezza massima illimitata nel modello).
:* Completamente asincrono: send non bloccante e receive non bloccante. Poco utilizzato, il destinatario deve fare un polling per controllare se il messaggio è arrivato o no.
:Per dimostrare la stessa espressività dei metodi dobbiamo sempre creare delle librerie e non dobbiamo aggiungere nessun processo.
:La metodologia asincrona è espressiva almeno quanto quella sincrona mentre non è vero il contrario.
:Per creare un metodo sincrono con chiamate asincrone basta bloccare il programma finché non si riceve un acknowledgement.
:Invece per creare un metodo asincrono con chiamate sincrone bisogna aggiungere un processo e quindi questo dimostra che non sono equivalentemente espressive.
* '''Soluzioni di esercizi d'esame'''
** Problema della lavatrice
** Problema del ponte a senso unico

== Lezione del 2 dicembre 2016 ==
* '''Implementazione della libreria per message passing'''
:I sorgenti della implementazione possono essere trovati [[Esperimenti con message passing in C|qui]]
* '''I segnali'''
:I segnali sono un metodo di comunicazione tra processi utilizzato in UNIX.
:Ogni segnale è rappresentato da un numero. Per esempio "segmentation fault" è il numero 11.
:La system call kill() serve per inviare un segnale. signal() serve per definire l'handler, una funzione che viene eseguita quando il processo riceve uno specifico segnale.
:Ogni segnale ha il suo handler di default e tramite signal() noi sovrascriviamo il default handler.
* '''Permesso setuid'''
:Permette a dei programmi di eseguire operazioni che hanno bisogno dei permessi di root. L'attributo setUserId attivato vuol dire che il programma verrà eseguito con i privilegi del possessore del file piuttosto di quelli di chi lo esegue.
* '''Proposta di soluzione esercizio 4 del [[Coding Contest 25 novembre 2016]]'''

== Lezione del 6 dicembre 2016 ==

* Implementazione di un servizio di Message Passing Asincrono dato uno sincrono (con processo server).
* Implementazione di un servizio di Message Passing completamente asincrono dato uno sincrono.
* Analisi del potere espressivo dei servizi di message passing.

* kernel monolitici e microkernel
* macchine virtuali a livello di processo e a livello di sistema

I sorgenti degli esperimenti con il message passing sono in [http://www.cs.unibo.it/~renzo/so/tools/mp.extra.tgz questo file].

== Lezione del 9 dicembre 2016 ==

* Il problema della Cena dei filosofi con il message passing (asincrono)

* Buffer Limitato con message passing (asincrono).

== Lezione del 13 dicembre 2016 ==

La lezione TACE per malattia (influenza) del docente.

== Lezione del 16 dicembre 2016 ==
*'''Specifiche del progetto fase uno'''
Il documento delle specifiche può essere trovato [http://www.cs.unibo.it/~renzo/so/mikaboo/phase1.pdf qui].
:*List.h
:*Lista dei processi
:*Coda dei thread
:*Code dei messaggi
*'''Autotools'''
:Insieme di strumenti per la generazione automatica di Makefiles. 
:comando ''autoreconf'' per generale il file ''configure'' 
:''./configure'' per generare makefile.

== Lezione del 21 febbraio 2017 ==
'''Argomenti trattati:'''
* '''Visione a strati di un elaboratore'''
:Gli strati sono livelli di astrazione. Ogni strato deve "parlare" il linguaggio del livello sottostante e deve fornire un proprio linguaggio ai livelli superiori.
:Per esempio il sistema operativo parla l'ISA del livello hardware e fornisce alle applicazioni le system call. Il sistema operativo maschera il livello hardware in quanto fornisce la possibilità alle applicazioni di utilizzare istruzioni ISA ma non tutte, per ragioni di sicurezza.
* '''Componenti fondamentali di un sistema operativo'''
:A sua volta il sistema operativo può essere visto come un insieme di strati. Esistono sistemi operativi a singolo strato (come MS-DOS) e più strati (layered).
:Le parti principali in cui possiamo suddividere un sistema operativo sono:
:*Lo scheduler
:*Il memory manager
:*Il file system
:*L'I/O manager
:*Il networking manager
:Di questa lista, gli elementi assolutamente fondamentali per considera un programma un sistema operativo sono lo scheduler e una parte essenziale del memory e I/O manager.
:Il networking e file manager si appoggiano al I/O manager per svolgere i loro compiti.
*'''Bootstrap'''
:Letteralmente "mettersi in piedi tirandosi dai lacci degli stivali", nel senso di attivarsi senza aiuto esterno. All'accensione il computer legge da una ROM le prime istruzioni necessarie. Viene sempre letto dai primi settori della memoria di massa il bootloader. :Il bootloader (per esempio GRUB) conosce già molti filesystem, ma non abbastanza. Il bootloader carica un file system temporaneo apposito chiamato initrd per caricare i moduli necessari al kernel.
*'''Come rappresentiamo i processi'''
:Dobbiamo sia tener conto a che punto siamo arrivati nell'esecuzione del processo sia tener conto delle risorse di cui il processo è detentore.
:Utilizziamo la struttura ''Process Control Block'' (task_struct in linux) per i processi e "Thread Control Block" (task_struct in linux) per i thread.
:Process control block:
:*PID (Process ID)
:*PPID (Parent Process ID) per poter creare una gerarchia di processi
:*punti di accesso alla memoria (codice,dati,tabella di rilocazione,paginazione)
:*lista dei thread
:*owner (se il sistema è multiuser)
:*Risorse del processo
:*Coda dei messaggi per IPC (Inter-Process Communication)
:*accounting (tempo di esecuzione sia in modalità kernel sia in modalità user)
:*valore di ritorno del processo
:Thread control block:
:*TID (Thread ID)
:*stato del processore
:*call stack
:*ready/running/waiting
*'''Avvicendamento dei processi'''
:Definizione di avvicendamento: ''Successione prevista o regolata nel tempo, alternanza.''
:I context switch avvengono a seguito di trap/interrupt.
:Il ciclo di vita di un processo passa tra gli stati ''ready, running, waiting'' e infine ''term''.
:Lo scheduling (processo decisionale) può venire applicato nelle seguenti 4 situazioni:
:# Quando un processo passa dallo stato di running a quello di waiting
:# Quando un processo passa dallo stato di running a quello di ready
:# Quando un processo passa dallo stato di waiting a quello di ready
:# Quando un processo passa dallo stato di running a quello di term
:Se lo scheduling avviene solo nella situazione 1 e 4 allora si utilizza un metodo non preemptive. Dal momento che la CPU è allocata a un processo questo la detiene finchè non termina o entra di sua spontanea volontà in stato di waiting. La CPU non può decidere di far aspettare un processo spostandolo temporaneamente nella coda dei processi ready. Questo sistema era utilizzato da vecchi sistemi operativi come Windows 3.x e dalle versione di Mac OS prima della versione X.
:Nel preemptive scheduling invece la CPU può decidere di sospendere un processo, questo può creare race condition ma anche un sistema più equo di distribuzione delle risorse. Le race condition vengono risolte con i metodi che abbiamo visto nel primo semestre.
'

== Lezione del 23 febbraio 2017 ==

'''System call'''

Abbiamo analizzato le system call che erano già presenti nella [http://man.cat-v.org/unix-6th/2/ versione 6 di Unix] (1975). 
Le abbiamo poi confrontate con quelle attuali del [[Il_%27%27catalogo%27%27_delle_System_Call]].

'''Shell Scripting'''

Gli script vengono utilizzati per lanciare un demone, guardare i processi, etc.
Anche l'amministrazione di sistema avviene tramite scripting. Ad esempio, dopo il boot, il processo init avvia le funzionalità di sistema tramite script.

Unix unifica l'idea di script con quella di shell.
La shell è un processo che interagisce con l'utente. In Unix la novità introdotta è rappresentata dalla presenza di un linguaggio che riguarda i comandi, utile per scrivere gli script per la shell.

Come indichiamo quale shell usare? Scrivendo nella prima riga #! seguito dal path e dal nome della shell. Il kernel prende ciò che è scritto nella prima riga e lo esegue per interpretare lo script.
Nell'esempio sottostante Script è un commento perchè è preceduto da #.

ESEMPIO

#!/bin/bash
#Script

echo "Hello World!"

Per scrivere script abbiamo bisogno di variabili. Nelle shell queste possono essere di 2 tipi:

- Locali: viste solo dalla shell, non perturbano comportamento dei processi.

- D'ambiente: recepita dai comandi come ambiente.

'''ASSEGNAMENTO E VARIABILI'''

ESEMPIO 1

a=2 /* Non devono esserci spazi!!! a = 2 doesn't work */
echo $a /* Stampa 2 */
echo ${a}a /* Stampa 2a */

ESEMPIO 2 - Nuova shell

bash /* Apro nuova shell */
echo $a /* Stamperà una riga vuota perchè la var. a non è locale della nuova shell */
exit /* chiudo nuova shell */

ESEMPIO 3 - Esportare variabile locale

export a /* La var. a diventa variabile d'ambiente */
bash
echo $a /* Ora possiamo chiamare la var. a perchè è diventata d'ambiente */

ESEMPIO 4 - csh

csh in molti casi dovrebbe già essere installato di default.
Se non è così è possibile installarlo eseguendo

sudo apt-get install csh

csh /* Apro cshell, noterete il simbolo di percentuale % a inizio riga di comando */
set a=42 /* assegnamento */
csh /* apro nuova shell */
echo $a /* non possiamo chiamare a(42) perchè locale alla prima shell, viene chiamata a d'ambiente se presente */
exit
setenv a 42 /* Per creare una variabile d'ambiente, da notare la mancanza di = */
csh
echo $a

'''ARGOMENTI'''

Negli script possiamo avere degli argomenti.
Vengono visti come $1, ..., $9, ${10}, etc.
$* indica tutti gli argomenti

ESEMPIO 1
#!/bin/bash
echo $* /* Richiama tutti gli argomenti */
echo $1 $2 /* Richiama solo i primi due argomenti */
shift /* Sposta la riga di comando degli argomenti di una posizione verso sx */
echo $*

Una volta salvato il file con estensione .sh, eseguire da terminale:
chmod +x nomefile.sh
./nomefile.sh arg1 arg2 ...

Se passiamo come argomenti: uno due tre quattro,
l'output sarà:
uno due tre quattro
uno due
due tre quattro

A volte dobbiamo proteggere dei caratteri. Alcuni di essi possono essere delle wildcard. Ci sono 3 modi per proteggerli:
\*
'*'
"*"

Analizziamone le differenze tramite un esempio.

ESEMPIO 1

echo \* // OUTPUT: *
echo '*$a' // OUTPUT: *$a
echo "*$a" // OUTPUT: *2

Nel primo caso l'escape vale solo per *. Nel secondo caso vale per tutta la stringa. Nel terzo caso vale per * e richiama la variabile.

ESEMPIO 2
echo ab // OUTPUT: ab
echo "ab" //OUTPUT: ab

echo a b //OUTPUT: ab <-- non rileva gli spazi
echo "a b" //OUTPUT: a b

== Lezione del 28 febbraio 2017 ==
'''Argomenti trattati''':
* '''Ciclo di vita di un kernel'''
: Dopo l'inizializzazione (Creazione di code, rilevazione di device, ecc..) si crea a "mano" il primo processo.
: L'esecuzione dello scheduler si alterna a quella dei processi. Quando un processo utente viene eseguito il kernel non ha più il controllo del flusso e gli viene restituito solo quando avviene un interrupt/trap.
* '''Parametri di valutazione di un algoritmo di scheduling'''
** % Utilizzo CPU: Bisogna cercare di tener utilizzata il processore il più possibile riducendo i momenti di inutilizzo (idle).
** Produttività (Throughput) Numero di processi completati per unità di tempo
** Tempo totale (turnaround time) Tempo totale impiegato dall'esecuzione del processo al completamente. Tiene conto del tempo speso in attesa oltre al tempo in esecuzione.
** Tempo di risposta: Tempo prima che un primo output venga generato dal momento in cui il processo viene eseguito. In un sistema interattivo è importante per non dare all'utente l'idea di malfunzionamento.
** Tempo di attesa. Non aspettando l'I/O ma bensì tempo speso nella ready queue.
* '''Processi CPU Bound e I/O Bound'''
:: I processi si possono dividere in queste due categorie. I processi che utilizzano il processore per tempi più lunghi (per esempio quelli di calcolo scientifico) si chiamano CPU Bound mentre quelli che richiedono spesso interazioni e si fermano ad aspettare l'I/O si chiamano I/O Bound. Algoritmi di scheduling differenti possono favorire o sfavorire una delle due categorie. L'obbiettivo e trovare un algoritmo che sia ottimale per tutti i processi.
* '''Algoritmi di scheduling'''
** First come first served
:: Lo scheduler implementa una semplice coda dei processi che hanno richiesto l'esecuzione. E' semplice da capire e creare ma il tempo medio di attesa per un processo può essere lungo. Dipende molto dall'ordine in cui vengono avvicendati processi CPU bound e I/O Bound. Un processo CPU bound può creare un ''effetto convoglio'' e far dipendere il tempo di attesa di altri processi che sono I/O bound al suo tempo di esecuzione. Questo algoritmo non è quindi equo.
:* Shortest job first
:: Forse più correttamente nominato algoritmo ''shortest next CPU burst''. Ad ogni processo viene associato il suo tempo di esecuzione e viene scelto dalla ready queue sempre il processo con il tempo più basso. Per determinare il tempo di esecuzione a priori si utilizza una media esponenziale dei tempi di esecuzione dello stesso processo nel passato. [[File:Media_esponenziale.png]] ''t'' sono le misurazioni recenti mentre 'tau' sono la storia più ''remota''. Il parametro alfa determina quanto la media esponenziale sia basata sulla storia recente o su quella passata.
:* Shortest remaining time first
:: SJF può essere preemptive oppure no. Nel caso preemptive prende il nome di ''Shortest remaining time first''. Se un processo A è in esecuzione e arriva un'altro processo B con tempo di esecuzione minore allora A viene fermato e viene eseguito B. La priorità di A nella coda è ora il tempo stimato rimanente.
:* Round robin
:: E' definita un unità di tempo, di solito tra i 10 e i 100 millisecondi, e ogni processo ha un tempo massimo di esecuzione pari a questa unità. I processi vengono avvicendati a turno in una coda. Un processo termina l'esecuzione o per sua volontà (il tempo rimasto del quanto di tempo non è considerato) oppure perchè è scattato l'interval timer. Nell'ultimo caso il processo viene inserito in coda come se fosse un processo appena arrivato. La performance di questo algoritmo dipendono molto da che tipi di processi si gestiscono e dalla dimensione dell'unita di tempo. Se questa è larga allora l'algoritmo è più simile a FCFS mentre un'unita di tempo piccola porta a più context switch e quindi a più overhead. L'unità di tempo andrebbe decisa in proporzione al tempo di context switch.
:* Scheduling a priorità
:: Ad ogni processo è assegnata una priorità che si riflette nella priorità che ha il processo nella ready queue.
:: La priorità di un processo può essere influenzata da fattori interni (come i requisiti di memoria) o esterni al sistema operativo (come ''l'importanza'' di un processo). L'algoritmo può essere non preemptive o premtive, nel caso in cui interrompa il processo attuale se arriva un processo con più priorità.
:: L'SJF può essere visto come un caso particolare di scheduling a priorità, in cui la priorità e appunto inversamente proporzionale al tempo di esecuzione.
:: Un problema dello scheduling a priorità è la starvation, che può essere risolta con il meccanismo di ''aging'' in cui un processo aumenta di priorità proporzionalmente al tempo cui rimane nella ready queue.
:* Scheduler multilivello
:: Questo è lo scheduler più completo in quanto divide i processi in gruppi e utilizza differenti algoritmi per ogni gruppo.
:: Una tipica suddivisione è quella di processi foreground e background, rispettivamente I/O bound e CPU bound. Per ogni gruppo viene creata una coda apposita.

== Lezione del 2 marzo 2017 ==

'''Shell Scripting'''

'$' seguito da caratteri esegue una sostituzione, questa può essere:

'''ESEMPIO 1 (contenuto)'''

echo $SHELL

echo $USER

'''ESEMPIO 2 (comando)'''

echo $ls

'''ESEMPIO 2.1'''

du -s $(ls -d *es) //du -s prende come input l'output del comando compreso tra parentesi tonde

'''ESEMPIO 3 (wildcard)'''

echo * // tutti file/dir
echo *es // file/dir che terminanon con es
echo *[lg]es // file/dir che terminanon con les/ges
echo ????? // file/dir con 5 caratteri

Queste wildcard servono per poter individuare insiemi di file in un colpo solo.

'''ESEMPIO 4 ($ come sintassi riconosciuta da grep)'''

grep '>$' *.c // trova tutte le linee che terminano con '>' all'interno dei file .c

'''ESEMPIO 5 (PID)'''

echo $$ // restituisce PID dello script nel quale viene eseguito

'''ESEMPIO 6a'''

echo $1 $2 $3 >/tmp/tmpscript //scrive i 3 argomenti in tmpscript

cat /tmp/tmpscript //lettura tmpscript
rm -f /tmp/tmpscript //rimozione tmpscript

Se cerchiamo di lanciare quasi contemporaneamente lo script dell'esempio 6 in due shell differenti, lo script non funziona perchè lavorano sullo stesso file. Possiamo quindi ricorrere all'utilizzo di $$.

'''ESEMPIO 6b'''

echo $1 $2 $3 >/tmp/tmpscript$$

sleep 3 //in modo da poter lanciare lo script in un'altra shell
cat /tmp/tmpscript$$
rm -f /tmp/tmpscript$$

'''ESEMPIO 7'''
grep bash myscript.sh >& dev/null //ridireziono l'output di grep sul "null device"
echo $? //restituisce 0 se il comando precedente è stato eseguito correttamente, 1 altrimenti

'''Gli operatori >> e <<'''

>> è simile a > ma scrive alla fine del file invece che all'inizio. 
<< serve invece per inserire l'input di un comando direttamente nello script, come mostrato nel successivo esempio della mail.

'''ESEMPIO 8 (script per inviare mail)'''

#!/bin/bash

mail $1 << ENDOFMESSAGE
ciao $1 questa è una mail di prova
ENDOFMESSAGE //etichetta usata per indicare il termine del messaggio

Con

echo $1; echo $2; ls

raggruppiamo una sequenza di comandi sulla stessa riga

'''ESEMPIO 9((|| &&)'''

Gli operatori || e && possono essere utilizzati per processare più comandi consecutivamente.

command || die

gcc -o hwx hw.c && ./hwx

'''ESEMPIO 10 (sottoshell)'''

Una lista di comandi all'interno di () viene eseguita in una sottoshell. Le variabili all'interno della sottoshell non sono visibili al di fuori del blocco di codice nella sottoshell. Sono variabili locali.

(cd subdir; ls) //eseguo un comando in un'altra directory

'''Pushd e popd'''

Simili al comando ''cd'' ma pushd inserisce i percorsi visitati in una pila e tramite popd e possibile ripercorrere a ritroso le directory visitate.

'''ESEMPIO 11 (background jobs)
ping google.com & //esegue ping in background
jobs //mostra la lista dei jobs in esecuzione
//poniamo che l'output di jobs sia "[1]+ In esecuzione ping google.com &"
kill -9 %1 //termina il processo con identificatore 1
''bg'' repristina un processo fermato con CTRL+Z. 
''fg'' riporta in primo piano un processo mandato in background.

'''test e type'''

''test'' serve a comparare valori e controllare il tipo dei file. 
la sintassi ''[]'' è un alias di test.
if [ $$ -eq '10853' ] ; then echo "il processo corrente ha pid 10853"; else echo "il processo corrente non ha pid 10853"; fi;
//che è equivalente a
if test $$ -eq '10853'; then echo "il processo corrente ha pid 10853"; else echo "il processo corrente non ha pid 10853"; fi;
''type'' invece mostra l'origine di un comando, se sono integrati nella shell oppure è un programma a parte.

'''Switch'''
Sintassi degli switch in bash.
case expression in
pattern1 )
statements ;;
pattern2 )
statements ;;
...
esac
'''Comando cron''' 
''cron'' serve per eseguire operazioni pianificate. Gli script in /etc/init.d vengono eseguiti automaticamente da cron.

'''xarg''' 
xarg permette di eseguire un comando passandogli come parametri i valori letti da standard input.

'''uniq''' 
uniq può essere usato per trovare e eliminare righe duplicate.

'''wc''' 
''wc'' crea il ''word count'' di un file. Non conta solo le parole ma anche i caratteri e le righe.

'''diff e patch''' 
Il comando ''diff'' può essere utilizzato per mostrare le differenze tra due file testuali. E' utilizzato internamente da git. 
Patch serve per applicare un ''diff file'' a un altro file in modo da aggiornarlo.

== Lezione del 7 marzo 2017 ==
Una risorsa è ogni elemento utile all'elaborazione.
* '''Classificazione di risorse'''
** '''Fisiche e logiche'''
::Esempi:
::CPU, memoria e dispositivi sono risorse ''fisiche''.
::file, strutture dati, critical section sono risorse ''logiche''.
:* '''Fungibili'''
::Una risorsa è fungibile se è uguale prendere un bene o un'altro se sono dello stesso tipo. Richiedere un area di memoria o un altra è indifferente se tutte e due soddisfano i requisiti del processo. Richiedere file o dispositivi differenti invece cambia.
:* '''Assegnazione statica o dinamica'''
::L'assegnazione statica prevede che una risorsa sia monopolio di un processo.
:* '''Accetta richieste multiple o solo singole'''
:: Se può ricevere richieste d'uso da più processi e memorizzare/servire contemporaneamente le richieste oppure no.
:* '''condivisibili e non condivisibili'''
:: Un file in lettura è una risorsa condivisibile, più processi possono accedere contemporaneamente. Un file in scrittura invece è una risorsa non condivisibile perché potrebbe capitare una race condition.
:* '''bloccante e non bloccante'''
::Se l'accesso alla risorsa implica dei tempi di attesa relativamente lunghi al processo, la risorsa è da considerarsi bloccante.
:* '''prelasciabile o non prelasciabile'''
::Il processo può rilasciare in qualsiasi momento la risorsa e permetterne l'uso ad un altro processo? Una stampante è un esempio di risorsa non prerilasciabile.
* '''Deadlock'''
:Un deadlock può avvenire in presenza di risorse bloccanti, non condivisibili, non prerilasciabili e con una situazione di attesa circolare.
:* '''detection: grafo di Holt '''
::I grafi di allocazione delle risorse, introdotti da Holt nel 1972 sono un buon modo per descrivere lo stato di un sistema e prevedere possibili deadlock. Ogni nodo rappresenta una risorsa o un processo. Di solito le risorse sono rappresentate da quadrati e i processi da cerchi. Un arco da un processo a una risorsa significa che quel processo ha richiesto un'istanza della risorsa. Un arco da una risorsa a un processo vuol dire che un'istanza di quella risorsa è stata assegnata al processo. 
::* ''' teorema dei cicli in grafi di Holt con un solo tipo di risorsa
:::Se il grafo non contiene cicli allora di sicuro non possono esserci deadlock.
:::Se il grafo contiene un ciclo allora può esserci un deadlock.
:::Se le risorse coinvolte in un ciclo hanno solo un'istanza o ogni loro istanza e coinvolta in un ciclo allora c'è di sicuro un deadlock.
:::Questo tecnica di permette di analizzare uno stato ''attuale'' di un sistema, ma dobbiamo trovare un modo per prevedere lo stato ''futuro'' del sistema e quindi prevedere i deadlock.
::* '''processo di riduzione
:::Per vedere lo stato di un sistema futuro possiamo usare un processo di riduzione del grafo di allocazione delle risorse.
:::Se una risorsa allocata a un processo può essere data dopo un certo periodo a un altro processo che l'ha richiesta allora si può fare una riduzione. Una riduzione consiste nell'eliminare un arco risorsa-processo perchè quel processo ha finito di utilizzare la risorsa oppure è stata prerilasciata e invertire un arco processo-risorsa di un processo che aveva richiesto la risorsa in un arco risorsa-processo.
:::Se un grafo può essere ridotto per tutti i suoi processi allora non può esserci deadlock.
:::Il problema di questo metodo/algoritmo è che nel momento che deallochiamo una risorsa a un processo e più processi avevano richiesto quella risorsa come scegliamo deterministicamente a quale processo assegnare la risorsa? Dovremmo provare tutti i casi per accertarsi che non si crei deadlock, ciò significa fare backtrack e perdere la polinomialità dell'algoritmo.
::* '''definizione di Knot
:::Il Knot è una caratteristica di un grafo che si verifica velocemente e permette di determinare possibili deadlock.
:::Un knot è un insieme di nodi in cui, per ogni nodo del knot, tutti e solo i nodi del knot sono raggiungibili da quel nodo.
:::Un knot è una condizione sufficiente ma non necessaria per i deadlock. Ciò vuol dire che possono capitare deadlock anche senza la presenta di un knot.
::* '''teorema dei knot nei grafi di Holt con più tipi di risorse
:::Dato un grafo di Holt con una sola richiesta sospesa per processo.
:::Il grafo rappresenta uno stato di deadlock solo se esiste un knot.
:* '''prevention'''
::Se il sistema cerca di non far verificare almeno una delle condizioni necessarie al deadlock allora questo non si verificherà mai.
::Questo però comporta anche sottoutilizzo delle risorse del sistema.
:* '''avoidance'''
::*'''Condizione di safety'''
:::Un sistema è in una condizione di safety se esiste una safe sequence.
:::Una safe sequence è una sequenza di processi dove per ogni richiesta di risorse di un processo questa richiesta può essere soddisfatta con le richieste disponibili al momento più tutte le risorse allocate precedentemente ai precedenti processi della sequenza.
:::Finchè c'è safety non possono verificarsi deadlock. In una situazione unsafe non è detto che capiti deadlock, ma è possibile.
::*'''algoritmo del Banchiere (mono e multivaluta).
:::L'algoritmo del banchiere si basa sul fatto che una banca non dovrebbe mai rimanere senza denaro da prestare ai clienti.
:::Vengono mantenute varie strutture dati come il capitale iniziale della banca, quanto è disponibile in cassa, quanto è stato prestato ad ogni cliente e quanto si può ancora prestare ad ogni cliente (in base al ''credito'' che ogni cliente ha).
:::La condizione di safety è data dalla condizione che bisogna mantenere almeno uno dei clienti soddisfacibile cioè che il denaro in cassa sia maggiore del possibile richiesta di prestito di almeno un cliente.
:::Se questa condizione non si verificasse alloca il banchiere deve aspettare che un cliente restituisca il prestito.
:::In caso di più valute (yen, dollari, euro, ...) che rappresentano i tipi diversi di risorse del sistema. Tutte le strutture dati aumentano di una dimensione, per esempio il denaro iniziale diventa un vettore.
::Teorema: il processo di controllo di safety non ha necessita' di backtrack.
:* '''Tecnica dell'ostrica/struzzo'''
::Un altro modo per gestire i deadlock e quello di ignorarli completamente.
::La maggior parte dei sistemi operativi utilizza questo metodo.
::Soprattuto in sistemi in cui è statisticamente determinato che i deadlock si verificano poco frequentemente i sistemi di prevenzione e avoidance costituirebbero un overhead troppo elevato.
::Sta allora alle singole applicazioni evitare di crearli.

== Lezione del 9 marzo 2017 ==

* awk
* phase2: prime fasi del boot
* python: presentazione del linguaggio ed analisi delle caratteristiche

== Lezione del 14 marzo 2017 ==
'''Gestione della memoria'''
* Binding a tempo di esecuzione, compilazione o esecuzione
* Memory Management Unit (MMU)
* Allocazione statica o dinamica
* Allocazione continua o non contigua
* Metodo delle partizioni fisse
: Problema della frammentazione interna.
* Metodo delle partizioni variabili
:Problema della frammentazione esterna.
:* Algoritmi di scelta dell'area di allocazione
:** First fit
:** Best fit
:** Worst fit
:** Next fit
:* Paginazione
:* Segmentazione
:* Memoria virtuale

== Lezione del 16 marzo 2017 ==
* '''Progetto phase2''': analisi del manuale di uARM
* '''Python''': funzioni, oop, @memoize, @trace

== Lezione del 21 marzo 2017 ==

La lezione del 21 marzo tace per impegno del docente.

== Lezione del 23 marzo 2017 ==
'''Memoria virtuale''': 
'''Algoritmi di paginazione:'''
Quando avviene un page fault serve un algoritmo per trovare la pagina "meno utile" in memoria a cui sostituire la pagina richiesta.
* '''FIFO''' viene sostituita la pagina che da più tempo è in memoria
* '''LFU''' ''Least Frequently Used'' contando il numero di richieste alla pagina possiamo calcolare quali sono le pagine più richieste e tenere solo quelle in memoria. Il problema è che una pagina potrebbe essere richiesta molto in una fase iniziale di un processo, quindi avere un rank elevato, però poi non essere più utilizzata. Una soluzione a questo problema è quella di shiftare a destra di 1 i bit del contatore degli utilizzi a intervalli regolari, ponendo questo in un decadimento esponenziale.
* '''LRU''' ''Least Recently Used'' si sostituisce la pagina che non è stata utilizzata da più tempo.
* '''Algoritmo ottimo''' algoritmo teorico utile per fare ''benchmark'' degli altri algoritmi. Se conosciamo a priori la ''reference string'' una sequenza che indica quali saranno le richieste delle pagine nel futuro, possiamo sostituire le pagine che per più tempo non saranno richieste, riducendo al minimo i page fault.
'''Anomalia di Belady'''
Abbiamo dimostrato che l'algoritmo FIFO all'aumentare della memoria può peggiorare di performance.

== Lezione del 28 marzo 2017 ==
'''Algoritmo second chance o dell'orologio''' 
'''Linking statico''' 
'''Loading dinamico''' 
'''Memoria secondaria''' 
'''Algoritmi di scheduling delle seek''' 
*'''FIFO'''
*'''SSF'''
*'''c-look'''

== Lezione del 30 marzo 2017 ==
'''Discussione sulle specifiche del progetto''' 
:Creazione pagina [[Specifiche_phase_2_2016/17]]
'''Python standard library'''
* libreria sys: Permette di prendere parametri da linea di comando. Si utilizza ''sys.argv''.
* libreria os: Permette di navigare nella gerarchia di directory con ''os.walk''.

== Lezione del 4 aprile 2017 ==
'''RAID''' 
(Redundant Array Inexpensive/Independent Disks)

l’idea principale nasce per ottenere maggiori performance (raid 0 ed 1), non maggiore affidabilità (raid 4 e 5).

* RAID0 (Striping): i dischi sono posti in sequenza.Vengono create le stripe, sequenze di bit che sono posti su n dischi sequenzialmente. Lo striping può essere a vari livelli, a livello di bit, di byte, di settore o di blocco. Quello più utilizzato e il livello di blocco. Cioè per scrivere un file che è composto da più blocchi si suddividono i blocchi in più dischi. Attenzione, file piccoli potrebbero sostare su una sola stripe, quindi su un solo disco.
:Il miglioramento di performance si paga in maggiore faultness. dipende dal costo dei dati salvati.

* RAID1 (mirroring): ogni disco ospita la copia dei dati. doppia velocità in lettura (teoricamente). Stessa velocita di scrittura.
: Size = ½ readSpeed = N wSpeed = ½ N FT = 1
* RAID10 = 1+0 striping su 2 mirror.

* RAID 2-3 (deprecated):Agisce sui singoli blocchi i dati vengono salvati in maniera sincrona con meccanismi di parità (hoffman per correzione di errori nel RAID2, ciclica per RAID3).

* RAID4: usa dischi normali, non agisce su singoli blocchi ma su stripe ampi.

parityMap = S0 XOR S1 XOR S2 XOR S3 (in caso di 4+1 dischi).

nel caso si rompa S4, i dati non avranno problemi. Se si rompesse un qualunque dei primi 4 dischi, basterà effettuare lo XOR degli altri e copiare tali dati su un nuovo HD.

S1 rotto.
new_S1 = S0 XOR S2 XOR S3 XOR P0123
Sopporta una sola rottura.

Per aggiornare il disco di parità in caso di modifica a S2 (chiamato ora S2’)

P0123 = P0123 XOR S2 XOR S2’.
il primo xor toglie il valore da P0123 di S2, il secondo XOR aggiunge il valore S2’.
in questo modo, aggiorno solo 2 dischi, e uso gli stessi in lettura per ricalcolare la parità.

Le parità ciclano su tutti i dischi. Esistono controller che effettuano RAID5, oppure e’ possibile ottenere le funzionalità raid via sistema operativo.

* RAID5:
:Senza fault
:Size = N-1/N, rspeed=(N-1), wspeed=(N-2), FT=1

I dischi RAID soffrono alquanto in caso di terremoti.

'''File System:''' 
Servizio per dare una interfaccia più comoda e generale per l’accesso alla memoria secondaria.

Nasce come informatizzazione delle pratiche di ufficio. le pratiche sono salvate in folders, fascicoli, poste poi nelle directories. come visualizzo questa struttura per l’utente? E ad i programmatori? come viene implementato?

Nasce l’idea di “aprire” i file. Nell'accedere da un programma ad il file-system (operazione non banale) si preferisce chiamare un’operazione di apertura, e utilizzare un descrittore al file per agire sul file richiesto.

La struttura di file/folder/directories possono inoltre supportare le astrazioni di condivisione e proprieta’.
Tutti i controlli sono effettuati sono in fase di apertura (in modo da migliorare le performance).

Quali attributi caratterizzano un file?
<ul>
<li>Name,</li>
<li>Type,</li>
<li>Location,</li>
<li>Size,</li>
<li>Ownership,</li>
<li>Protection,</li>
<li>Time stamp</li>
</ul>
UNIX opta per una scelta minimalista. Tutti i file sono stringhe di byte.
AFS (Apple) da un tag di tipo e di creator per ogni file

maggiore e’ il numero di tipi di file, maggiore supporto per essi, ma piu’ codice nel kernel.
I suffissi possono indicare ad altri programmi il tipo.

Semantica della coerenza vs Semantica delle sessioni (Andrew File System)

Per quali motivo vengono create le partizioni?
/var andrebbe in una nuova partizione per un fattore di sicurezza.

Cosa c’e’ effettivamente sul disco? Una sequenza di blocchi, il cui primo (boot block) ha spazio per il bootloader e la tabella delle partizioni (MBR), con 4 elementi. 4 record che indicano dove ogni partizione inizia e finisce. Si possono usare partizioni estese, usando le prime 3 e nella quarta tutto il resto.

Ogni partizione ha all'inizio un BootRecord.
L’ultima partizione contiene nel BootRecord le altre partizioni.
GBT consente di avere un numero arbitrario di partizioni.

Raizer FS,

Read only file systems.

Initrd, ISO9660.

Quando si costruisce l’immagine, in realtà si sta creando il file-system ISO9660.

Come gestire invece file che possono cambiare?
Allocazione indicizzata (a lista): creo un (o vari) blocco/i degli indici che punta ad i blocchi dati.
l’accesso diretto cresce come il logaritmo dell’ampiezza.
Allocazione concatenata (ad albero): (in fondo al blocco indico il successivo). Gestisce bene la dinamicità. Non piace perché’ non é per nulla efficiente l’accesso diretto.

Quali allocazioni usano i filesystem reali oggi?

fat: concatenata. I blocchi tengono solo i dati, esiste una file allocation table (vettore) che indica il prossimo blocco. I puntatori sono tutti vicini e quindi ponendo il vettore in cache, abbiamo disponibili diversi puntatori.

BerkleyFastFileSystem (progenitore dei EXT4…) usano allocazione indicizzata. Nasce per garantire performance ad i file piccoli. Nel descrittore del file (iNode) avra’ N (13 attualmente) puntatori. Uno, il numero 10, ad i blocchi, uno (11) indiretto alla tabella, uno (12) come duplice indiretto e il 13esimo come triplice indiretto.

I file hanno quindi una lunghezza massima. EX4 pero’ risolve indicizzando non i singoli blocchi ma le serie.

Gestione spazio libero

nella struttura indicizzata serve una struttura per tenere conto degli spazi liberi. Si puo’ usare una bitmap per tenere la contabilità degli spazi liberi e quelli utilizzati.

== Lezione del 6 aprile 2017 ==

File System. Ext2 e VFAT. Sicurezza, principi generali.

== Lezione del 11 aprile 2017 ==

Sicurezza: crittografia (chiave pubblica/chiave segreta) autorizzazione autenticazione firma elettronica.
Virus Worm Cavalli di Troia.

Attacchi buffer overflow e toctou.

== Lezione del 20 aprile 2017 ==

(tace per impossibilita' del docente)

== Lezione del 27 aprile 2017 ==

P2test (prestest2).

DIscussione specifiche.

== Lezione del 2 maggio 2017 ==
== Lezione del 4 maggio 2017 ==
* Discussione su proposta da parte degli studenti di modifiche al test di progetto
* Soluzione all'esercizio C1 del 2014-06-16 (Monitor)
* Soluzione all'esercizio 1 del [[http://www.cs.unibo.it/~renzo/so/pratiche/2015.05.29.pdf 2016-05-20]] ( C )
* Soluzione all'esercizio 2 del 2008-06-13 (Dimostrazione algoritmo di rimpiazzamento a stack)
* Soluzione all'esercizio 1 del [[http://www.cs.unibo.it/~renzo/so/compiti/2013.07.19.tot.pdf 2013-07-19]] (Monitor)

== Lezione del 9 maggio 2017 ==
*Esercizio 2 prova teorica 2014.09.24
*Esercizio g.1 prova teorica 2013.07.19
*Esercizio c1 e c2 prova teorica 2015.01.20(2014.01.20)
*Esercizio c2 2013.05.30

== Lezione del 11 maggio 2017 ==
== Lezione del 16 maggio 2017 ==
* Chiarimenti su svolgimento esame
* Commenti su recenti eventi (WannaCry)
* Visione di programma python per costruzione di stringhe palindrome con monitor
* Correzione esercizio g2 prova teorica 20170209
* Correzione esercizio 1 [[Prova pratica 2016.09.13]]
* Esercizio c2 prova teorica 20140122

== Lezione del 18 maggio 2017 ==

Prova teorica 2017.05.29

2017-06-15T09:41:15Z

FedericoB: Creata pagina con link a foto del compito e struttura. Aggiunta risposa domanda 2 esercizio g.2

File:20170529.jpg

2017-06-15T09:24:42Z

FedericoB: Foto della prova teorica del 2017.05.29. Quando sarà disponibile online il pdf si potrà eliminare questa immagine.

Foto della prova teorica del 2017.05.29. Quando sarà disponibile online il pdf si potrà eliminare questa immagine.

Prova teorica 2016.01.21

2017-06-15T09:16:45Z

FedericoB: Creata pagina e aggiunta risposta alla domanda 3 del esercizio g.2

[http://www.cs.unibo.it/~renzo/so/compiti/2016.01.21.ris.pdf link al compito]
==Esercizio g.2==
===Soluzione di FedericoB===
# '''Quali sono i casi di frammentazione interna ed esterna che possono avvenire usando la paginazione.'''
# '''Per I file system di tipo fat non e' efficiente l'accesso diretto (ad esempio con la system call lseek) a file di grandi dimensioni. Perche'?'''
# '''Per quali tipi di processo e' indicato uno scheduler a priorita' statica? Quale problema puo' essere causato da uno scheduler a priorita' statica? perche'?''' Lo scheduler a priorità statica è indicato per i processi i cui fattori che determinano la priorità rimangono costanti per tutta la durata del processo. Un processo che riesce a ottenere una priorità elevata rispetto agli altri la manterrà per tutta l'esecuzione. Però questo può causare starvation dei processi con meno priorità. Per ovviare a questo si utilizza il meccanismo di ''aging'' cioé si riduce progressivamente la priorità di un processo in base al tempo in cui questo è stato in esecuzione.
# '''Cosa e' un knot in un grafo? Quale teorema lega la definizione di knot in un grafo e la presenza di deadlock fra processi?'''

Prova teorica 2017.01.18

2017-06-15T08:55:39Z

FedericoB: Creata pagina e aggiunte risposte a domande 3,4,5 esercizio g.2

[http://www.cs.unibo.it/~renzo/so/compiti/2017.01.18.ris.pdf link al compito]

==Esercizio g.2==

# '''Perché un algoritmo di rimpiazzamento a stack non soffre dell’anomalia di Belady?'''
# '''Perché si può usare un meccanismo di crittografia simmetrica nella gestione delle capability di accesso alle risorse?'''
# '''Quali operazioni svolge il processore per la gestione di un interrupt e quali invece sono a carico del kernel del sistema operativo?''' Il processore si occupa, all'attivazione della linea elettronica dell interrupt di recuperare dalla memoria in locazioni fisse l'indirizzo delle istruzioni di gestione degli interrupt. In seguito carica questo indirizzo nel program counter e quindi "salta" a queste istruzioni attivando la modalità di esecuzione kernel mode. Le routine di gestione degli interrupt fanno parte del codice kernel e si occupano di gestire opportunamente le operazioni necessarie in base al tipo di interrupt. Per esempio operazioni come eseguire lo scheduler o recuperare l'output di un device.
# '''Perche’ il mascheramento degli interrupt non si può utilizzare per creare sezioni critiche in sistemi multicore o multiprocessore?''' Il mascheramento degli interrupt previene l'interruzione del esecuzione del processo corrente e il context switch a un altro processo e di conseguenza la non atomicità delle istruzioni che stava eseguendo il processo. Anche disabilitando gli interrupt (è uguale se su un solo processore o su tutti) c'è comunque la possibilità che altro codice eseguito in ''parallelismo reale'' vada in concorrenza con quello dove si sta cercando di ottenere una sezione critica.
# '''Per quali tipi di processo l’algoritmo di schedulazione round-robin è efficiente e per quali no?''' L'algoritmo di schedulazione round-robin è efficente per i processi I/O bound in quanto è ''fair'', cioè permette a tutti i processi il diritto di esecuzione entro un certo lasso di tempo. Può non essere efficiente per i processi CPU bound che hanno tempi di esecuzione lunghi e il round robin li costringe a ritardare il loro completamento. Inoltre un processo CPU bound potrebbe essere interrotto quando manca davvero poco al suo termine ma il time slice è terminato oppure necessita di I/O.Il processo viene messo in coda e bisognerà aspettare l'esecuzione di tutti gli altri processi prima di poter finire l'esecuzione.Uno scheduler shortest remaining time first avrebbe invece rimesso subito in esecuzione il processo CPU bound se il tempo di esecuzione previsto rimanente era davvero ridotto.

Prove teoriche

2017-06-15T08:24:22Z

FedericoB: Aggiunti link a soluzioni mancanti da febbraio 2015 a oggi

''Qui troverete alcune prove teoriche svolte, in modo da poter discutere sull'elaborato''

''Le prove sono svolte da studenti e servono come base per la discussione. Le soluzioni possono essere errate''

[[Prova teorica 2017.05.29]]

[[Prova teorica 2017.02.09]]

[[Prova teorica 2017.01.18]]

[[Prova teorica 2016.09.15]]

[[Prova teorica 2016.07.27]]

[[Prova teorica 2016.05.30]]

[[Prova teorica 2016.02.10]]

[[Prova teorica 2016.01.21]]

[[Prova teorica 2015.09.14]]

[[Prova teorica 2015.07.29]]

[[Prova teorica 2015.06.17]]

[[Prova teorica 2015.05.28]]

[[Prova teorica 2015.02.14]]

[[Prova teorica 2015.01.20]]

[[Prova teorica 2014.09.24]]

[[Prova teorica 2014.07.16]]

[[Prova teorica 2014.06.16]]

[[Prova teorica 2014.06.03]]

[[ProvaTeorica 2014.02.22]]

[[ProvaTeorica 2014.01.22]]

[[Prova Teorica 2013.09.12]]

[[Prova teorica 2013.07.19]]

[[ProvaTeorica 2013.07.19]]

[[Prova Teorica 2013.06.21]]

[[Prova_Teorica 2013.02.14]]

[[ProvaTeorica 2013.01.24]]

[[ProvaTeorica_2012.09.18]]

[[ProvaTeorica 2012.07.16]]

[[ProvaTeorica_2012.06.15]]

[[ProvaTeorica_2012.05.24]]

[[ProvaTeorica_2012.02.09]]

[[ProvaTeoria 2012.01.12]]

[[ProvaTeoria_2011.07.25]]

[[Prova Teorica 2011.05.13]]

[[ProvaTeorica_2011.02.11]]

[[ProvaTeoria 2011.01.17]]

[[ProvaTeoria 2010.05.12]]

[[Prova Teorica 2009.09.18]]

[[ProvaTeoria_2009.01.30]]

[[Prova Teorica 2008.09.17]]

[[Prova Teorica 2008.01.16]]

[[Prova Teorica 2007.09.07]]

[[Prova Teorica 2007.07.12]]

[[ProvaTeorica 2005.11.04]]

Prova teorica 2017.02.09

2017-06-15T08:13:51Z

FedericoB: Creata pagina e aggiunta risposta a domanda 1 esercizio g.2

[http://www.cs.unibo.it/~renzo/so/compiti/2017.02.09.ris.pdf link al compito]

==Esercizio g.2==
===Soluzione di FedericoB===

#'''Perché uno scheduler non preemptive non è adatto per processi interattivi?'''

:Perchè la presenza di un processo CPU bound potrebbe rallentare l'accesso alla risorsa a processi che necessitano di tempi di risposta all'utente rapidi. Essendo lo scheduler preemptive uno processo potrebbe detenere l'esecuzione per un tempo considerevole e altri processi dovrebbero attendere in quando non è possibile utilizzare un time slice per far terminare prima il processo CPU bound.

Prove teoriche

2017-06-15T08:04:10Z

FedericoB: Aggiunta link alla prova teorica del 2017.02.09

''Qui troverete alcune prove teoriche svolte, in modo da poter discutere sull'elaborato''

''Le prove sono svolte da studenti e servono come base per la discussione. Le soluzioni possono essere errate''

[[Prova teorica 2017.02.09]]

[[Prova teorica 2015.02.14]]

[[Prova teorica 2015.01.20]]

[[Prova teorica 2014.09.24]]

[[Prova teorica 2014.07.16]]

[[Prova teorica 2014.06.16]]

[[Prova teorica 2014.06.03]]

[[ProvaTeorica 2014.02.22]]

[[ProvaTeorica 2014.01.22]]

[[Prova Teorica 2013.09.12]]

[[Prova teorica 2013.07.19]]

[[ProvaTeorica 2013.07.19]]

[[Prova Teorica 2013.06.21]]

[[Prova_Teorica 2013.02.14]]

[[ProvaTeorica 2013.01.24]]

[[ProvaTeorica_2012.09.18]]

[[ProvaTeorica 2012.07.16]]

[[ProvaTeorica_2012.06.15]]

[[ProvaTeorica_2012.05.24]]

[[ProvaTeorica_2012.02.09]]

[[ProvaTeoria 2012.01.12]]

[[ProvaTeoria_2011.07.25]]

[[Prova Teorica 2011.05.13]]

[[ProvaTeorica_2011.02.11]]

[[ProvaTeoria 2011.01.17]]

[[ProvaTeoria 2010.05.12]]

[[Prova Teorica 2009.09.18]]

[[ProvaTeoria_2009.01.30]]

[[Prova Teorica 2008.09.17]]

[[Prova Teorica 2008.01.16]]

[[Prova Teorica 2007.09.07]]

[[Prova Teorica 2007.07.12]]

[[ProvaTeorica 2005.11.04]]

Lezioni Anno Accademico 2016/17

2017-06-14T20:27:50Z

FedericoB: /* Lezione del 28 febbraio 2017 */ Corretto typo

''scrivete qui idee, riassunti dei concetti espressi, commenti approfondimenti sulle lezioni.''

== Lezione del 23 settembre 2016 ==

'''YY'''

* Presentazione del corso.
* Strumenti del corso: web, wiki.mailing list
* Indice dei contenuti
* Prove di esame (Scritto, Prova Pratica, Progetto).

* Hardware Software
* Informatica
* Informazione/Dato
* Rivoluzione digitale (secondo rinascimento, Terza rivoluzione Industriale).
* Software Libero

== Lezione del 27 settembre 2016 ==

'''OS:Y'''

* '''Organizzazione (martedi' vs. venerdi')'''
In genere la lezione del martedì sarà più teorica mentre quella del venerdì più orientata agli aspetti pratici di laboratorio. Questa suddivisione potrebbe cambiare in quanto qualche martedì verrà saltato.
* '''Università'''
Università = studenti + docenti
* '''Digitale/Analogico'''
Digit significa cifra. Nell'informatica è fondamentale il passaggio dal continuo al discreto.
* '''Binario/Decimale'''
Nei calcolatori l'informazione è memorizzata utilizzando il sistema binario ...
(''in quanto in passato i relè consentivano di avere due stati: " 1 e 0 "'': è impreciso, qualcuno sa dare una definizione migliore? [[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 12:00, 29 September 2016 (CEST)) 
In quanto è molto semplice implementare le operazioni aritmetiche con dei circuiti elettronici utilizzando la codifica binaria. Per esempio è possibile creare un [https://it.wikipedia.org/wiki/Half-adder circuito] che somma due bit con riporto con solo due porte logiche. [[User:FedericoB|FedericoB]] ([[User talk:FedericoB|talk]]) 17:05, 29 September 2016 (CEST)
* '''I linguaggi e i problemi dell'Informatica'''
**Processing dell'informazione (Linguaggi di programmazione)
**Comunicazione (Il problema che i dati che mi servono sono in un altro luogo) (Linguaggi dei protocolli di rete, che però sono dei linguaggi temporizzati)
**Memorizzazione (Il problema che i dati mi serviranno in futuro) (Linguaggio del formato dei dati)
* '''Conoscenze a lungo, medio e breve termine nell'Informatica.'''
**BREVE: tecnologia, determinati programmi di sviluppo.
**MEDIO: singoli linguaggi, singoli OS, protocolli di comunicazione.
**LUNGO: algoritmi, informatica teorica, fondamenti costruttivi di reti e di OS.

* '''Cos'è una distribuzione'''
E' un antologia di applicazioni e librerie in modo che siano compatibili tra loro.

* '''Sistema Operativo: perché'''
Un sistema operativo è un programma che controlla l’esecuzione di programmi applicativi e agisce come interfaccia tra le applicazioni e l’hardware del calcolatore. 
E' uno strumento software complesso ed implementabile in diversi modi (monolitico, microkernel, etc.). I microcontroller non hanno OS.
Permette: contabilità delle risorse (consente a sua volta attività di benchmarking); continuità dei servizi; controllo errori
(programmi, dispositivi); multiuser (gli utenti hanno diversi diritti e proprietà sulle risorse); protezione delle attività dei
processi; astrazione file system.
* '''Struttura a livelli (layer)'''

---------------
---------------
---------------
OS
---------------L'
hw
---------------L

Consente di: separare la complessità, di avere portabilità.
Ogni livello rappresenta un cambio di linguaggio.
Più aggiungiamo livelli più aumenta il livello di astrazione.
* '''Programma/processo'''
Algoritmo: sequenza finita di istruzioni non ambigue, atta a risolvere un problema.

Programma: traduzione degli algoritmi in un linguaggio di programmazione.

Processo: istanza esecutiva di un programma. Il programma è testo statico, quando viene eseguito diviene processo. Possiamo avere
uno stesso programma in esecuzione su più processi (e.g apertura di più terminali che eseguono un editor di testo).

System call: richieste di processi al OS. e.g. printf (visto nel codice compilato in assembly tramite gcc -s), invoca write().
vi è una sequenza di azioni del tipo: richiesta di stampa al kernel --> attesa --> risposta.
* '''Storia dell'Informatica prima dei transistor'''

La storia dei calcolatori non ha un inizio preciso. Nel 1900 venne trovato sul relitto di una nave greca risalente al II secolo a.C un meccanismo in grado di calcolare i movimenti degli astri, si ipotizza con una sorprendente meccanica. Oggi questo sistema viene conosciuto come Macchina di Anticitera. Negli ultimi anni di ricerche archeologiche e storiche è venuta sempre più in superficie una vena pionieristica nel mondo classico per quanto riguarda lo studio sul calcolo automatizzato e addirittura di automi (si veda Erone di Alessandria). Ma facciamo un salto in avanti di qualche secolo... 
Già nel XVII secolo Pascal teorizza e mette in pratica uno strumento in grado di addizionare e sottrarre, e nel 1672 G.W. von Leibniz lo perfeziona con l'aggiunta della moltiplicazione e della divisione. Ma è solamente nei primi anni del 1800 che entra in scena la macchina analitica di Babbage. Estremamente complessa, la macchina era dotata di un sistema di input e di elaborazione dati e di un sistema di output. Ed è con Babbage che nascono le schede perforate. La macchina analitica venne presentata per la prima volta in Italia, durante un convegno torinese del 1840. Tra i vari collaboratori scientifici alla macchina è da annotare la presenza di Luigi Federico Menabrea, che tra le altre cose fu Ministro della Marina Militare, ingegnere e Presidente del Consiglio dei Ministri del Regno d'Italia (1867-1869). Il primo vero programmatore della storia, collaboratrice di Babbage, è Ada Lovelace (figlia del poeta Lord Byron!): progettò un algoritmo in grado di elaborare i numeri di Bernulli. 
Nel 1896 viene fondata la Tabulating Machine Company (futura IBM) e agli albori del '900, vari scienziati (trai quali Thomas Edison e Guglielmo Marconi) portarono avanti gli studi sulla valvola termoionica, elemento indispensabile dei primi calcolatori elettronici. La valvola incrementò vertiginosamente i tempi di calcolo ma l'estrema fragilità della stessa causò una serie di problematiche che si risolsero solamente con l'entrata in gioco del transistor.

== Lezione del 30 settembre 2016 ==

'''YC'''

(Storia dopo l'avvento del transistor)

Tre innovazioni indipendenti:
* Multitasking: Inizialmente ideato per mantenere la CPU occupata con altri processi mentre si faceva Input/Output. Permette di dare l'idea al utente di poter eseguire più processi contemporaneamente anche se questi in realtà sono eseguiti dalla cpu in modo intervallato. Ci sono certi computer che hanno più esecutori e quindi possono realmente eseguire multipli processi contemporaneamente.
* Supporto Multiuser
* Interattività:l'interazione con l'utente cambia il flusso del programma.

Queste tre proprietà sono ortogonali quindi possono esistere nei sistemi varie combinazioni di queste.

Iniziano anche a separarsi i ruoli tra programmatori e utenti.Prima i computer venivano utilizzati solo da chi creava programmi ora anche da chi li utilizza senza avere le conoscenze per crearli.

Il Time Sharing.

Sistemi Paralleli (SIMD/MIMD)
Sistemi Real Time

Dal 1969: UNIX.

Il linguaggio C e la portabilità dei sistemi operativi.
Caratteristiche del linguaggio C:
* grande controllo sul codice generato
* costrutti per l'elaborazione a basso livello
* supporto per la programmazione strutturata
* linguaggio "leggero": poche parole chiave, I/O gestito tramite librerie
* Il compilatore C è scritto in C.

Portabilità di un compilatore. I cross-compiler.

Il comando UNIX cc (o gcc): un comando unico per attivare l'intera toolchain per generare un eseguibile.

Il punto e virgola trasforma espressioni in istruzioni (terminatore).

1975? l'avvento dei personal computer. (in realtà il primo PC forse e' la Perrottina Olivetti del 1964).

Compiti a casa:
Portare esperimenti in C ritenuti "difficili".

[[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 10:41, 1 October 2016 (CEST)

== Lezione del 7 ottobre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7TzJXUTJZM3RBUlE 7\10\16]
* '''Esempi di programmi in linguaggio C'''
Abbiamo commentato i programmi dal 1.1 al 1.7 che si possono trovare in questa [[2016-17_Programmi_C|pagina]].
* '''Economia Push/Economia Pull'''
Nell'economia push si basa la produzione sulla previsione di domanda e la si cerca di aumentare tramite la pubblicità. Questa è stata la principale metodologia utilizzata nei secoli scorsi.
Al giorno d'oggi si sta facendo avanti un differente approccio chiamato "economia pull" dove la produzione è basata sulla domanda effettiva. Per esempio per richiedere un finanziamento per l'economia push l'approccio comune è tramite una banca a cui si chiede un prestito in base alle previsioni di ricavo. Invece nell'economia pull è esemplare il fenomeno del crowdfounding dove si riceve un finanziamento dalla "folla" cioè da un gruppo di persone che dona una piccola parte di denaro ciascuna in base al reale interesse per il prodotto/servizio.
* '''Sistemi Operativi e parallelismo'''
Più processi si dicono in esecuzione concorrente quando accedono a risorse condivise.
Un programma è multithread quando tutti i thread condividono la stessa memoria. Ogni thread deve avere un suo stack.
La concorrenza si studia in particolare in sistemi operativi in quanto un sistema operativo multitasking è un sistema concorrente.
Concorrenza di processi in architetture SMP (Symmetric multiprocessor system) e non. (RD: non mi pare di aver spiegato cosa sia l'SMP) 
Simulazione del fenomeno della '''race condition'''. Si ha '''race condition''' quando un programma concorrente può puo' produrre diversi risultati se eseguito piu' volte per colpa della diversa evoluzione temporale delle elaborazioni. 
Per risolvere questo dovremmo raggruppare le istruzioni in ''sezioni critiche'' (sequenze inscindibili di istruzioni che devono essere eseguite come se fossero atomiche, tutta la sequenza o niente).
* '''Architettura a livelli e virtualizzazione'''
Dato un A e un A’ e riusciamo a usare A’ come A, allora A’ lo possiamo chiamare A virtuale.
L'idea che alla base delle macchine virtuali è di creare un interprete di un ISA differente o uguale a quello del sistema in modo da virtualizzare una reale macchina hardware e quindi poterla usare per gli stessi scopi di una macchina reale. E' quindi possibile, per esempio, installare sistemi operativi su hardware virtuale. 
L'insieme dei componenti hardware virtuali e il software installato su di questi prende il nome di ''macchina virtuale''.
Uno dei principali vantaggi, oggi molto utilizzato in ambito cloud, è quello di poter suddividere facilmente risorse hardware fisiche, per esempio spazio su disco e potenza di elaborazione, tra macchine virtuali differenti.
* '''Laboratorio di cross-compiling'''
Nel ultima parte della lezione abbiamo fatto un esperimento sulla portabilità dei compilatori. 
Abbiamo a disposizione un linguaggio ad alto livello che chiameremo L, due interpreti hw0 e hw1 per linguaggi a basso livello che chiameremo lhw0 e lhw1 e infine due compilatori L->lhw0 uno scritto in python e l'altro in L. 
Se compiliamo con il compilatore scritto in python (abbiamo un interprete python installato sulla macchina che stiamo utilizzando) il compilatore scritto in L otteniamo un compilatore scritto in lhw0 L->lhw0. 
Se ora modifichiamo il compilatore scritto in L L->lhw0 in modo che crei codice per hw1 (basta modificare gli indici numerici delle istruzioni) otteniamo un compilatore in L L->lhw1. Se lo compiliamo con il compilatore L->lhw0 otteniamo un ''cross-compiler'' scritto in lhw0 L->lhw1, cioè un compilatore che crea codice eseguibile su una macchina diversa da quella attuale. 
Se ora utilizziamo il cross compiler L->lhw1 per compilare il compilatore scritto in L L->hw1 otteniamo invece un compilatore che può essere eseguito su hw1. 
A questo punto su hw1 potremmo utilizzare l'ultimo compilatore creato per compilare sempre il compilatore scritto in L L->hw1 ma vedremo che otterremo sempre lo stesso file perché avremo raggiunto il limite.
 
Il materiale per poter replicare l'esperimento sulla portabilità dei compilatori è [http://www.cs.unibo.it/~renzo/so/tools/portability3.tgz qui].
[[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 13:42, 8 October 2016 (CEST)

== Lezione del 11 ottobre 2016 ==
*'''C'''
<syntaxhighlight lang=C>
#include <stdio.h>

void dump (void* f, size_t len){ //size_t is the sizeof() return type
unsigned char *s = f;
size_t i;
for (i = 0; i < len; i++)
printf("%02x ",s[i]); //%02x means print at least 2 digits and add 0's if there are less
printf("\n");
}

int main(){

int v[] = {1, 2, 3, 4}; //v is (int*) 0x32ef...
v[2] = 42; //*((int*) 0x32ef) + 2 = 42, moves the address by 2 "positions", aka 4+4 bytes
v[2] = 0x33;//(int*) 0x32ef.. = 0x33 (i.e.) 4 = 42

char s[] = "ciao";
int t[] = {0x63, 0x69, 0x61, 0x6f, 0x00}; //ciao in ASCII hex. if int OUT:'c'. if char OUT:"ciao"
char u[] = {99, 105,97, 111, 0 }; //ciao in ASCII dec. OUT:"ciao"

char *q = "ciao";
char *w = "mare";

printf("%s\n", s);
printf("%s\n", t);
printf("%s\n", u);

dump(s, sizeof(s));
dump(t, sizeof(t));
dump(q, sizeof(*q)); //*q size is 1B (it points to 1 char). OUT: 63('c')
dump(q, sizeof(q)); //q size is 8B. OUT: 5B of "ciao" + 3B of contiguous string "mare"
}
</syntaxhighlight>

OUTPUT:
<pre>
ciao
c
ciao
63 69 61 6f 00
63 00 00 00 69 00 00 00 61 00 00 00 6f 00 00 00 00 00 00 00 //int are 4B, char 1B, so we have empty bytes.
Little endian pattern is evident. %s allow to print untill the first null, so printf prints just 'c' with int declaration of t[]
63
63 69 61 6f 00 6d 61 72 // 6d = m, 61 = a, 72 = r.
</pre>

* '''Assioma di finite progress.'''
"Tutto è vero purchè ogni statement abbia durata sconosciuta, ma finita"
* '''Modalità di concorrenza.'''
1- Inconsapevolmente concorrenti: ogni processo elabora ciò per cui è stato creato. Il kernel si occupa di coordinazione e comunicazione.

2- Indirettamente concorrenti: processi che accedono a file condivisi.

3- Consapevolmente concorrenti: il programma ha diversi processi in esecuzione.
*''' Convenzioni usate nel corso (e negli esami) relative alle istruzioni atomiche'''
Le istruzioni atomiche vengono compiute in modo indivisibile, garantendo che l'azione non interferisca con altri processi durante la sua esecuzione.
Vengono rappresentate nel seguente modo:
<pre>
<istruzione atomica>
</pre>
Anche gli statement sono istruzioni atomiche(escluso il caso long long).
*''' Proprieta' di Safety e Liveness'''
-Safety: se il programma evolve, evolve bene(S)

"''Something good'' happens"

-Liveness: il programma va avanti(L)

"''Something eventually'' happens"

* '''Problema del consenso.'''
Il problema è così definito: ci sono n processi, ognuno propone un valore. Al termine tutti i processi devono accordarsi su di 1 dei valori proposti.Il suddetto problema è risolvibile se e solo se vengono rispettate le seguenti proprietà (2 di Safety + 1 di Liveness)

Proprietà:

S(1)- Tutti i processi devono ritornare lo stesso valore

S(2)- Ogni processo corretto decide uno tra i valori proposti

L(1)- Ogni processo corretto deve dare una risposta

w/o S(1): f(x) = x

w/o S(2): f(x) = 42

w/o L(1): f(x) = while(1)

*w/o = without

* '''Problemi delle elaborazioni concorrenti. Prima definizione (non formale) di Deadlock e Starvation'''
Introduzione alla notazione per la rappresentazione dei processi concorrenti

ESEMPIO 1.0

process p {
...
...
}

process q {
...
...
}

Due processi eseguiti in concorrenza.

...
cobegin
...
//
...
//
...
coend

cobegin e coend indicano la sezione di codice con le istruzioni (rappresentate da "..." e separate da "//")che verranno eseguite in concorrenza.

ESEMPIO 1.1 - Merge sort
cobegin
sort(v[1 : N])
//
sort(v[N : N])
//
merge(v[1 : N]), v[N : M])
coend

Se isoliamo le istruzioni senza considerare cobegin e coend, lo pseudocodice è corretto.
Se consideriamo anche cobegin e coend il programma esegue la funzione di merge() in concorrenza con le due chiamate a sort(), utilizzando risorse in comune e pertanto cercando di ordinare elementi non ancora ordinati nelle due metà dell'array.
Se spostiamo l'invocazione di merge al di fuori della sezione cobegin ... coend, lo pseudocodice (vedi in basso) è corretto.

cobegin
sort(v[1 : N])
//
sort(v[N : N])
coend
merge(v[1 : N]), v[N : M])

In particolare nella programmazione concorrente si devono affrontare due problemi che riguardano la liveness, parliamo di deadlock e starvation.

'''DEADLOCK''': uno o più processi non possono continuare l'esecuzione perchè ognuno di essi è in attesa che gli altri facciano qualcosa

ESEMPIO 1.2

process p {
while 1:
prendi a
prendi b
calcola f(a,b)
lascia a
lascia b
}

process q {
while 1:
prendi a
prendi b
calcola f(a,b)
lascia a
lascia b
}

Supponiamo di invertire l'ordine di prendi a e prendi b nel processo p. Dopo che entrambi i processi eseguono la prima istruzione lo scenario che si sviluppa è il seguente: al processo p serve la risorsa a, presa dal processo q, al quale servirebbe la risorsa b, presa dal processo p. I processi aspettano a vicenda che uno rilasci la risorsa che possiede l'altro. Risorsa necessaria ad entrambi i processi per eseguire l'istruzione (f(a,b)) che le richiederebbe entrambe. I processi sono deadlocked.

'''STARVATION''': quando un processo attende una risorsa indefinitamente, e questa non gli viene mai allocata

ESEMPIO 1.3
process p {
while 1:
prendi a
calcola f(a)
lascia a
}

process q {
while 1:
prendi a
calcola f(a)
lascia a
}

Supponiamo che i processi per realizzare "prendi a" verifichino la disponibilità di a tramite polling (provando ripetutamente se a è libero). Il processo q può essere sfortunato e non riuscire mai ad avere accesso ad a (tutte le volte che cerca di "prenderlo" lo troverà impegnato da p). Il processo q è in starvation.

ESEMPIO 1.4
"Supponiamo di avere tre processi (P1, P2, P3) i quali richiedono periodicamente accesso alla risorsa R. Consideriamo la situazione nella quale P1 è in possesso della risorsa, e sia P2 che P3 attendono per quella risorsa. Quando P1 esce dalla sua sezione critica, a P2 o P3 dovrebbe essere permesso l'accesso a R. Assumiamo che il SO garantisca l'accesso a P3 e che P1 richieda nuovamente la risorsa prima che P3 termini la sua sezione critica. Se il SO dovesse garantire l'accesso a P1 dopo che P3 abbia finito, e successivamente dovesse garantire alternativamente a P1 e P3 l'accesso alla risorsa, allora P2 potrebbe vedersi indefinitamente negato l'accesso alla risorsa, sebbene non vi sia una situazione di deadlock" (Stallings W.(2015). ''Operating System: internals and design principles''. (8th ed). Pearson)

'''Problema: posso creare sezioni critiche, tramite la programmazione, senza aiuti hardware?'''

ESEMPIO

process p
/*enter_cs*/
A = A + 1
/*exit_cs*/

process q
/*enter_cs*/
A = A - 1
/*exit_cs*/

'''Le 4 proprietà della critical section(CS)'''

SAFETY(1): una operazione all'interno della CS

ESEMPIO
process p
while 1:
/*enter_cs*/
A = A + 1
/*exit_cs*/
... <--- process q deve poter "entrare" qui

LIVENESS(1): no deadlock

LIVENESS(2): no starvation

LIVENESS(3): no useless wait

''Dekker(1st attempt) //KEY: turno''

turn = p //var globale condivisa

process p{
while (turn != p)
;
/*A = A + 1*/
turn = q
...
}

process q{
while(turn != q)
;
/*A = A - 1*/
turn = p
...
}

Non rispetta la proprietà di liveness(3), infatti uno dei due processi può dover attendere a lungo il suo turno eseguendo ciclicamente l'empty statement all'interno
del corpo del while. Questa situazione può verificarsi se l'altro processo fallisce dentro o fuori la sua CS (in questo caso l'attesa è infinita). Inoltre visto che i processi si alternano strettamente nell'utilizzo della loro critical section, il ritmo di esecuzione è dettato dal processo più lento dei due.

''Dekker(2nd attempt) //KEY: flag, ma senza turno''

inp = false

inq = false

process p{
while 1:
while(inq)
;
inp = true
/*A = A + 1*/
inp = false
...
}

process q{
while 1:
while(inp)
;
inq = true
/*A = A - 1*/
inq = false
...
}

In questo caso se uno dei processi fallisce fuori dalla CS (dopo aver settato il flag a false) l'altro processo non viene bloccato. Se invece un processo fallisce nella sua CS oppure dopo aver settato il flag a true allora l'altro processo resta bloccato indefinitamente. Non è garantita inoltre la mutua esclusione in quanto entrambi potrebbero essere al contempo nelle loro rispettive CS, ad esempio:

p valuta la condizione del while e trova inq a false

q valuta la condizione del while e trova inp a false

p assegna true a inp ed entra nella sua CS

q assegna true a inq ed entra nella sua CS

....entrambi sono nella rispettiva CS --> no liveness(1)

''Dekker(3nd attempt) //KEY: come 2nd ma con due istruzioni scambiate di ordine''

process p{
while 1:
inp = true
while(inq)
;
/*A = A + 1*/
inp = false
...
}

process q{
while 1:
inq = true
while(inp)
;
/*A = A - 1*/
inq = false
...
}

Scambiando l'ordine di due istruzioni vi è la mutua esclusione, tuttavia se entrambi i processi assegnano true al loro rispettivo flag, prima di valutare la condizione
del while, entrambi resteranno all'interno del while in attesa che l'altro processo "esca dalla CS" (non vi è mai entrato) --> deadlock

''Dekker(4nd attempt) //KEY: flag + delay''

process p{
while 1:
inp = true
while(inq){
inp = false; < delay >; inp = true;
}
/*A = A + 1*/
inp = false
...
}

process q{
while 1:
inq = true
while(inp){
inq = false; < delay >; inq = true;
}
/*A = A - 1*/
inq = false
...
}

In questo caso il settare il proprio flag a true è indice del desiderio di entrare nella propria CS. Vi è ancora mutua esclusione. Se però dovesse verificarsi una sequenza del tipo:

p imposta flag inp a true

q imposta falg inq a true

p valuta la condizione del while

q valuta la condizione del while

p imposta flag inp a false

q imposta flag inq a false

p imposta flag inp a true

q imposta flag inq a true

allora c'è la possibilità che si ripeta all'infinito (entrambi i processi potrebbero rimanere nel while). Essendo però una condizione che dipende dalla velocità relativa dei due processi, esiseranno delle situazioni nelle quali uno dei due processi potrà entrare, così come vi saranno delle situazioni nelle quali nessun processo avrà accesso alla propria CS --> livelock

'''Dekker...finally //KEY: flag + turni ("cambio delay con turno)'''

needp = false

needq = false

turn = p

process p{
while 1:
needp = true
while (needq) {
needp = false
while(turn == q)
;
needp = true
}
/*A = A + 1*/
needp = false
turn = q
...
}

process q{
while 1:
needq = true
while(needp) {
needq = false;
while(turn == p)
;
needq = true
}
/*A = A - 1*/
needq = false
turn = p
...
}

In questo caso il processo che vuole entrare nella sua CS ne manifesta il bisogno settando need a true. Se entrambi i processi entrano nel corpo del while il tie-break è espletato dal while la cui condizione è un turn che sarà uguale soltanto ad uno dei due processi (in questo caso turn è inizializzata a p), e dunque non si verificherànno situazioni di deadlock o livelock.
*'''Proprietà della sezione critica'''
Mutua esclusione 
Assenza di deadlock 
Assenza di starvation 
Assenza di delay non necessari

*'''La test&set'''
E' un istruzione atomica per impostare il valore di una variabile a 1 (lock) ma ritornare il vecchio valore. Questa istruzione può essere utilizzata per gestire sezioni critiche. 
Il valore ritornato dalla test and set viene comparato a 1, se è uguale si aspetta altrimenti si procede. 
In questo modo il primo processo che cercherà di entrare nella sezione critica ci riuscirà e imposterà il lock a 1, gli altri processi si troveranno il lock a 1 e dovranno aspettare. Quando il primo processo avrà finito ripristinerà il vecchio valore di lock e permetterà a uno degli altri processi di eseguire la test and set e di entrare nella sezione critica.
----
Altri argomenti trattati che non sono stati qui riportati in forma di appunti:
Gestione algoritmica della critical section.
Algoritmo di Dekker.
Gestione architetturale della critical section.

[[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 10:35, 17 October 2016 (CEST)

== Lezione del 14 ottobre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7UlJadTRVbzhWRFE 14\10\16]
* Sistemi Operativi per elaboratori multiprocessore SMP/non SMP
* Macchine di von Neumann (e di Harvard).
* Il bus.
* Interrupt e Trap
* Gestione degli interrupt
* Mascheramento degli interrupt
* Interrupt Nidificati
* DMA
* Device a carattere e device a blocchi
* System call come trap.
* La gerarchia delle memorie
* cache

== Lezione del 18 ottobre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7eVlFdWR0cUkxd2M 18/10/16]

Argomenti trattati:
*'''Implementazione in C della Test&Set, degli Algoritmi di Dekker e Peterson.'''
Codice sorgente disponibile [[Dekker,_Peterson_e_Test%26Set_in_C|qui]].
*'''Definizione di Semaforo.'''
Un semaforo è una variabile intera che può essere modificata solo da 2 operazioni atomiche: P(Proberen) e V(Verhogen). 
P aspetta che il valore sia minore o uguale a zero. Quando lo diventa decrementa il valore. 
S incrementa il valore. 
*'''Invariante del Semaforo.'''
Il numero di Proberen deve essere minore o uguale al numero di Verhogen più il valore d'inizializzazione del semaforo. 
In questo modo si può gestire per esempio l'allocazione di risorse. Il semaforo viene inizializzato al numero di risorse e ogni volta che un processo ha bisogno della risorsa esegue un proberen, quindi decrementa il valore se la risorsa è disponibile. Quando un processo rilascia la risorsa esegue un verhogen.
*'''Esempio: implementazione di sezione critica e di semplice sincronizzazione con semafori.'''

== Lezione del 21 ottobre 2016 ==
*'''Make'''
Make è un sistema per la compilazione intelligente dei programmi. 
Permette invece di compilare tutto il programma tutte le volte di compilarne solo una parte, solo quella che è stata modificata.
Per capirne il funzionamento è utile un parallelismo con le ricette di cucina. Si specificano dei target che sono gli obbiettivi della ricetta.Per fare una ricetta servono degli ingredienti e magari quegli ingredienti hanno a loro volta delle ricette. Make allo stesso modo definisce dei target che possono avere come dipendenze altri target. 
Nel installazione del programma il programma ./configure cerca nel sistema se le librerie da cui è dipendente il programma sono presenti. 
*'''Git'''
Git è un sistema di versioning, serve a tener traccia delle modifiche apportante a un progetto nel tempo. E' utile per collaborare a un progetto condiviso. 
Possibilità per ogni membro del repository di lavorare in maniera indipendente e poi aggiornare il progetto comune. 
Ce ne sono stati tanti di sistemi di versioning tipo SVN, Mercurial ma attualmente Git è il più utilizzato. 
Git non serve solo per scrivere programmi ma per esempio anche libri, in modo collaborativo. 
Git è completamente distribuito, non esiste in un repository una copia principale e delle copie secondarie ma ogni copia può essere principale. 
Per iniziare un repository git si utilizza il comando ''git init''. 
Per aggiungere un file al repository si utilizza il comando ''git add''. 
Ma ad ogni singola modifica git non aggiorna automaticamente il repository ma è l'utente che tramite il comando git commit indica che una certa versione del progetto deve essere salvata. 
Il comando ''git log'' serve a visualizzare la storia del repository. 
Il comando ''git diff'' serve a vedere la differenza tra ciò che è nel repository e le modifiche di cui non si è ancora fatto il commit. 
Dopo aver dato il comando add si dice che i file sono 'on stage' prima del commit. 
Il comando ''git checkout'' serve a spostarsi nella storia del repository. 
Il comando ''git clone'' serve a copiare un repository remoto. 
Il comando ''git push'' serve a inviare le modifiche al repository remoto mentre il comando ''git pull'' serve a ricevere le modifiche più aggiornate dal repository remoto. 
Il ''merge'' è il processo in cui uno degli utenti che crea un conflitto deve "a mano" scegliere quali parti dei due commit in conflitto vuole tenere. 
Git è utile per trovare i bug che non erano presenti in versioni precedenti del progetto. Si può tornare alla versione precedente stabile e avanzare nella storia fino a trovare una versione instabile. A questo punto è probabile che l'origine del bug sia nelle modifiche che hanno creato questa versione instabile. 
Github è una piattaforma di repository dove possono essere mantenuti dei progetti gratuitamente se sono con licenza libera. 
In una directory in cui è presente un repository git e sempre la presente la cartella ''.git'' dove il sistema di versioning mantiene il database della storia. 

== Lezione del 25 ottobre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7WjZJMm11cjhuQXc 25/10/16]

Argomenti trattati:
* '''Semafori fair'''
Un semaforo è "fair" quando tende a non sbloccare dallo stato di attesa sempre lo stesso processo ma cerca di distribuire la possibilità di esecuzione a più processi.
* '''Problemi classici della concorrenza risolti con semafori'''
** '''Produttore/consumatore'''
::Due processi: produttore e consumatore. Il produttore genera continuamente dei valori e il consumatore continuamente li legge. Il consumatore deve leggere i valori nello stesso ordine in cui il produttore li genera. 
::Un meccanismo di sincronizzazione e richiesto perchè sorgono immediatamente due problemi:
::* Produttore troppo veloce: il consumatore non fa in tempo a consumare il valore e c'è la possibilità che i valori non ancora letti vengano sovrascritti.
::* Consumatore troppo veloce: possibilità che il consumatore legga un valore che ha già letto perchè il produttore non ha fatto in tempo a produrne uno nuovo.
::Per risolvere il problema utilizziamo due semafori: empty e full. 
::Il produttore aspetta che il segnale del semaforo empty (Proberen), scrive il valore e dà segnale sul semaforo full (Verhogen). 
::Il consumatore aspetta il segnale del semaforo full (Proberen), legge il valore e dà segnale sul semaforo empty (Verhogen). 
:* '''Buffer-limitato'''
::Simile al problema produttore/consumatore ma qui lo scambio avviene tramite un buffer limitato. 
::In questo modo nel caso di rallentamento temporaneo del consumer il producer non deve aspettare ma può produrre più unità e viceversa nel caso di rallentamento del producer, se il buffer ha più di un elemento, il consumer può utilizzare il tempo in attesa del producer per consumare più dati. 
::Nel caso il buffer sia completamente pieno/vuoto rimangono comunque i problemi di sincronizzazione tipici del problema: il producer non deve sovrascrivere dei valori che il consumer non ha ancora letto e il consumer non deve leggere più volte lo stesso valore se il producer non è stato abbastanza veloce da cambiarlo. 
::Come soluzione al problema si può utilizzare un coda circolare. Il produttore esegue una enqueue e il consumatore una dequeue. 
::Il problema può essere generalizzato facilmente a produttori/consumatori multipli ma in questo caso dobbiamo creare un semaforo per rendere atomiche la enqueue e la dequeue altrimenti incorriamo in una race condition nel accesso alla coda.

== Lezione del 28 ottobre 2016 ==

'''Implementazione dei semafori''' 
Un processo che esegue una Proberen in teoria dovrebbe aspettare continuando a controllare se può entrare nella sezione critica. Questo meccanismo si chiama "busy waiting" e consuma molte istruzioni della CPU. 
Il busy waiting è diverso dal polling in quando il polling prevede di eseguire altre azioni mentre si aspetta tra un tentativo e l'altro. 
Di solito si utilizza il busy waiting solo quando il tempo di lock di un processo è molto breve. Questo perchè anche se esoso di risorse del processore il busy waiting non comporta un context switch, cioè salvare tutto lo stato del processo in memoria, e quindi permette di risparmiare memoria.
Se invece il tempo di lock è più lungo allora è preferibile utilizzare un context-switch dove il processo si blocca da solo e chiama un processo di blocking che lo mette in una coda di attesa associata al semaforo che sta aspettando. Il controllo passa poi allo scheduler della CPU che seleziona un altro processo da eseguire.
Le primitive suspend and wakeup indicano rispettivamente lo spostamento di un processo nella/dalla coda dei processi ready.
* nei kernel monoprocessore
: Implementazione dei semafori tramite mutex che possono essere a loro volta implementate con un sistema di mascheramento degli interrupt.
* nei kernel multiprocessore
: Utilizzo di soluzioni hardware come test and set. Sono soluzioni che utilizzano il busy waiting ma in questo caso solo per rendere atomico le operazioni del semaforo, che sono poche istruzioni.
Certe implementazioni dei semafori potrebbero permettere di far andare il valore in negativo. Questo serve per misurare il numero dei processi in attesa di quel semaforo. 
'''Il problema della cena dei filosofi''': 
5 filosofi passano la loro vita pensando e mangiando. Condividono un tavolo circolare con 5 sedie e ogni sedia appartiene a un solo filosofo. Alla sinistra e alla destra di ogni piatto c'è una bacchetta per un totale di 5 bacchette. La bacchetta destra che un filosofo usa per mangiare viene quindi utilizzata come bacchetta sinistra dal filosofo alla sua destra e simmetricamente è uguale per il filosofo che siede a sinistra. 
Ogni tanto un filosofo smette di pensare e cerca di prendere le rispettive bacchette, se ci riesce può mangiare e poi rilasciare le bacchette. 
Questo problema è un modello di problema ad accesso a ''insiemi'' di risorse. Mentre nel produttore/consumatore e buffer limitato gli attori in gioco avevano la necessità di avere l'accesso esclusivo a una sola risorsa in questo problema è richiesto l'accesso a insiemi di risorse (le bacchette) le cui parti possono essere desiderate da altri richiedenti.
* soluzione con contesa sulle posate e casi di deadlock
:Poniamo un semaforo per ogni bacchetta. Può succedere però, se nel implementazione i filosofi "prendono in mano" prima la bacchetta destra e poi quella sinistra, che tutti prendono in mano contemporaneamente la bacchetta destra e rimangono in un'attesa infinita della bacchetta sinistra che non gli verrà mai rilasciata perché anche il rispettivo filosofo alla propria sinistra è in attesa. Questo è un caso di deadlock. 
:Una soluzione può essere quella di imporre che un filosofo sia "mancino" cioè prenda prima la bacchetta a sinistra e poi la destra. 
* soluzione con acquisizione atomica di entrambe le posate, casi di starvation
:Un'altra soluzione è quella di rendere atomico l'acquisizione di entrambe le posate. 
:Può succede che 4 filosofi compiano una "congiura", cioè siano d'accordo a non lasciar risorse a un quinto filosofo. Questo è un caso di starvation e non è irreale in quando i 4 filosofi potrebbero essere processi malevoli che siano stati programmati di proposito per questo.
'''System Call''':
* POSIX.
:Il POSIX è uno standard (IEEE 1003) che definisce le signature delle system call. Un sistema operativo deve rispettare il POSIX per essere definito "Unix-like". 
:Di solito i parametri delle system call sono pensati per essere contenuti in un registro. Quasi sempre le system call ritornano un intero: 0 se la procedura è stata eseguita correttamente, -1 se c'è un errore. Quando una system call ritorna -1 la variabile "globale" errno (error number) contiene il codice di errore. La variabile errno non è realmente globale perché ne esiste una per ogni processo. 
:Unix è un sistema operativo file-system centrico quindi quando facciamo input/output anche da periferiche come stampanti e lettori CD usiamo le system call per la scrittura/lettura dei file. 
:Un catalogo delle system call principali può essere trovato [[Il ''catalogo'' delle System Call | qui]].
* fork/exec
:fork e exec sono system call importanti e servono per creare un nuovo processo: 
:fork: genera un processo clone di quello che ha chiamato fork. 
:exec: "cambia" il codice eseguito dal processo corrente. 
:Quindi per "aprire un nuovo programma" si utilizza una fork seguita da un exec.

== Lezione del 4 novembre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7blhMT0tSNDRGSUU 4/11/16]

* '''Problema della Cena dei filosofi'''. Soluzione con acquisizione atomica delle bacchette (con starvation)
* '''Tecnica del passaggio del testimone''' (Passing the Baton).

: Non uscire dalla mutua esclusione se c'è qualcun altro che vuole entrarci e semplicemente fare in modo che lui l'acquisisca. La mutua esclusione termina solo se non c'è nessuno che più la richiede.

ESEMPIO IMPLEMENAZIONE BATON
<syntaxhighlight lang=C>
void baton(int i) {
int j;
for (j=1; j<5; j++) {
if(philo_status[(i+j)%5] == 'W' && philo_status[(i+j+1)%5] != 'E' && philo_status[(i+j+4)%5] != 'E') {
semaphore_V(philowait[(i+j)%5]);
return;
}
}
semaphore_V(mutex);
}
</syntaxhighlight>
* '''Cena dei filosofi, acquisizione atomica delle bacchette con passaggio del testimone'''.
* '''Implementazione della congiura dei filosofi'''

* '''Le system call di gestione file (open, read, write, close, lseek)'''
Quando lavoriamo con dei file dobbiamo sempre specificare se vogliamo solo leggerli oppure anche scrivere, magari in append mode. Ci sono quindi varie modalità con cui possiamo interagire con i file. 
Un utente potrebbe essere autorizzato a gestire il file in certe modalità oppure no. 
Il descrittore di un file è un intero. 
Le system call, a differenza delle chiamate di funzioni di libreria, non sono bufferizzate.

ESEMPIO

Se si decommenta printf stampa 2 volte hello world perchè la stringa resta nel buffer.

Se si decommenta write stampa 1 volta hello world.

Per vedere le chiamate di sistema effettuate in fase di esecuzione, compilare il codice sorgente e poi utilizzare strace -f "eseguibile".
<syntaxhighlight lang=C>
#include<stdio.h>
#include<unistd.h>

int main(int argc, char* argv[]){
//printf("hello world"); //if you ends the strings with \n is like to "fflushing" the buffer
//write(1, "hello world", 11); // 1 and 11 are file descriptors
switch(fork()) {
case 0: //child
break;
default: //parent
wait(NULL);
break;
case -1: //error
break;
}
printf("\n");
return 0;
}
</syntaxhighlight>

Copia il file passato come primo argomento (argv[1]) nel file passato come secondo argomento (argv[2]), se quest'ultimo non esiste, allora lo crea.
<syntaxhighlight lang=C>
#include<stdio.h>
#define BUFSIZE 2048
char buffer[BUFSIZE];
int main(int argc, char *argv[]){
int fdin = open(argv[1], O_RDONLY);
int fdout = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, 0666); //0666 is the umask used to modify the permissions of new files

int n;
while((n = read(fdin, buffer, BUFSIZE)) > 0)
write(fdout, buffer, n);

close(fdin);
close(fdout);
return 0;
}
</syntaxhighlight>

'''umask''' 
Con la open possiamo usare dei permessi al massimo per quelli garantiti dal umask. 
Un numero composto da quattro cifre ottali. Controlla la maschera di creazione dei file. I bit di permesso contenuti nella maschera NON vengono settati nel nuovo file creato. Corrisponde all'opereazione:

R:(D &(~M))

Può essere vista come una sottrazione, i bit accesi nella umask vengono spenti nel file creato.

e.g. se i permessi di default corrispondono a 0666(D) e la maschera corrisponde a 0022(M), R è uguale a 0666-0022 = 0644. Infatti

0022 = |000|000|010|010|
~0022 = |111|111|101|101|(7755)
0666 = |000|110|110|110|
~0022 & 0666 = |000|110|100|100|(0644)

Tabella significato cifre umask

OTTALE BINARIO SIGNIFICATO
0 000 Nessun permesso
1 001 Solo esecuzione
2 010 Solo scrittura
3 011 Scrittura ed esecuzione
4 100 Solo lettura
5 101 Lettura ed esecuzione
6 110 Lettura e scrittura
7 111 Lettura, scrittura ed esecuzione

I permessi sono rappresentati in simboli come segue:

r: read
w: write
x: execute

'''umask - S''' da shell per visualizzare la umask attuale con rappresentazione simbolica

'''ls -l "nomefile"''' da shell per visualizzare i permessi del file in notazione simbolica: '-' seguito da 3 triple che indicano i permessi di accesso per '''ugo''', ovvero, rispettivamente, per user, per group, per other.

ESEMPIO
-rw-r--r--

* '''File aperti durante fork/exec'''https://www.kernel.org/

I file aperti vengono ereditati dai processi figli.
Processo padre e processo figlio condividono lo stesso offset nei file comuni. In questo modo si evita di sovrascriversi a vicenda. Ogni volta che il padre o il figlio scrivono sul file aggiornano l'offset comune.In questo modo se l'altro processo vuole anche lui scrivere in quel file partirà dal offset aggiornato e non sovrascriverà i dati scritti dal altro processo. 

* '''La system call dup e la ridirezione'''
E' possibile fare in modo che più file descriptor siano associati a un unico file (per la precisione a un unica file table, che serve per gestire un file). 
La system call dup permette di fare ciò. Ritorna un nuovo file descriptor che punta a una file table già esistente. 
Possiamo quindi "ridirezionare" l'output o l'input di un processo figlio modificando i file descriptor prima di creare il processo figlio. Per esempio possiamo modificare un file descriptor che puntava a un normale file in modo che punti a un file di standard output e quindi anche se al processo figlio sembrerà di scrivere in un normale file starà scrivendo nel terminale.

ESEMPIO

<syntaxhighlight lang=C>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>
#include<stdio.h>
#include<unistd.h>

int main(int argc, char * argv[]){
int fdout;
if(argc > 1);
fdout = open (argv[1], O_WRONLY | O_CREAT | O_TRUNC, 0666);
switch(fork()) {
case 0: //child
dup2(fdout, 1); // duplica descrittore file, posso ridirezionare l'output. E' come fare '>' dalla shell
execlp(”ls”, “-l”, 0);
close(fdout);
break;
default: // parent
wait(NULL);
break;
case -1: // error
break;
}
printf(“\n”);
return 0;
}
</syntaxhighlight>

== Lezione del 8 novembre 2016 ==
'''Codice per la congiura dei filosofi'''
<syntaxhighlight lang=C>
#include <stdio.h>
#include <stdint.h>
#include <pthread.h>
#include "semaphore.h"

semaphore philowait[5];
semaphore mutex;
semaphore cospsem;
char philo_status[]="TTTTT";

void baton(int i){
int j = 0;
//iterate through remaining philosophers
for(j = 1; j < 5;j++){
//if there's any waiting philosopher, and no other philosophers(on his left and right side) are eating
if(philo_status[(i+j)%5]=='W' && philo_status[(i+j+1)%5]!= 'E' && philo_status[(i+j+4)%5]!='E'){
semaphore_V(philowait[(i+j)%5]);
return;
}
}
semaphore_V(mutex);
}

void ok2eat(int i){
semaphore_P(mutex);
philo_status[i]='W';
if(philo_status[(i+1)%5] == 'E' || philo_status[(i+4)%5] == 'E'){
semaphore_V(mutex);
semaphore_P(philowait[i]); //wait for baton
}
philo_status[i] = 'E';
printf("philo eating: %d |%s|\n",i,philo_status);
baton(i);
}

void ok2think(int i){
semaphore_P(mutex);
philo_status[i] = 'T';
printf("philo thinking: %d |%s|\n",i,philo_status);
baton(i);
}

void conspiracy_in(){
static int first_time = 1; //this variable's value is preserved between calls to this function
semaphore_P(mutex);
if(first_time){
//first conspirator entering here will act like nothing happened
first_time = 0;
}
else{
//conspire
semaphore_V(cospsem);
}
semaphore_V(mutex);
}

void conspiracy_out(){
semaphore_P(cospsem);
}

void *philo(void *arg) {
int i = (uintptr_t)arg;
while (1) {
//thinking/still thinking
usleep(random() % 200000);
ok2eat(i);
//eating

//conspirators need to be synchronized to conspire
if(i==1 || i==3) conspiracy_in();
usleep(random() % 200000);
if(i==1 || i==3) conspiracy_out();
ok2think(i);
//thinking again
}
}

int main(int argc, char *argv[]) {
int i;
pthread_t philo_t[5];
srandom(time(NULL));
mutex = semaphore_create(1);
cospsem = semaphore_create(0);
for (i=0; i<5; i++)
philowait[i]=semaphore_create(0);
for (i=0; i<5; i++)
pthread_create(&philo_t[i], NULL, philo, (void *)(uintptr_t) i);
for (i=0; i<5; i++)
pthread_join(philo_t[i], NULL);
}
</syntaxhighlight>

* '''Problema dei lettori e scrittori'''
:Spesso quando gestiamo la concorrenza all’accesso a strutture dati separiamo i ruoli di solo lettori con anche quello di scrittori (che per fare ciò possono dover anche leggere).
:Mentre che per i lettori non c’è un limite a quanti contemporaneamente possono avere accesso alle informazioni, gli scrittori devono avere accesso esclusivo alla struttura dati.
:Questo perché incorriamo in una race-condition solo quando modifichiamo la struttura dati.
:Dare precedenza di accesso a una categoria o all’altra porta starvation nella categoria con meno priorità.
:Una soluzione che abbiamo dato è quella di dare esclusività ai ruoli a turno:
:dopo che uno scrittore ha finito di scrivere garantisce l’accesso prima a tutti i lettori in attesa e se non sono presenti agli scrittori in attesa. Per i lettori è il contrario: dopo che l’ultimo lettore ha finito di leggere garantisce l’accesso a uno dei possibili scrittori in attesa e se non ce ne sono ai lettori.
:La soluzione in C al problema lettori e scrittori può essere trovata [[Zibaldone|qui]].
* '''Semafori Binari(Introduzione)'''
: Un semaforo binario è un semaforo ordinario che rispetta la seguente invariante: '''nP<=nV+Init<=nP+1''', ovvero è un semaforo che può assumere solo valori 0 o 1.
: Si può dimostrare che i semafori ordinari sono espressivi tanto quanto quelli binari(e viceversa) fornendo una implementazione di semafori binari tramite i semafori ordinari e viceversa una implementazione di semafori ordinari tramite semafori binari. (l'invariante dei semafori binari si può anche scrivere '''0 <= nV + Init - nP <= 1''' dove '''nV + Init - nP''' rappresenta proprio il valore del semaforo).

== Lezione del 11 novembre 2016 ==
* '''Valore di ritorno di un processo'''
:Un processo ritorna un valore che è un numero intero. 
:Questo può essere deciso come valore di ritorno del main, oppure con la funzione ''exit''.
:La system call wait aspetta che lo stato di un processo figlio cambi e quando cambia scrive il nuovo in una variabile. 
:Quando un programma termina il suo valore di ritorno viene salvato nel descrittore del processo. Se il padre non esegue la wait il descrittore del processo figlio non verrà mai eliminato e il processo figlio rimarrà uno "zombie".
:Un esempio del uso si queste system call si può trovare [[2016-17_Programmi_C#Print_child_exit_status|qui]].
* '''Pipe'''
:La system call pipe crea un canale monodirezionale che può essere usato per la comunicazione tra processi. Dimostrazione del uso di pipe si può trovare [[2016-17_Programmi_C#Demonstration_of_the_use_of_pipe_system_call|qui]].
* '''Lo zoo delle exec'''
<syntaxhighlight lang='C'>
int execl(const char *path, const char *arg, ...);
int execlp(const char *file, const char *arg, ...);
int execle(const char *path, const char *arg, ..., char * const envp[]);
int execv(const char *path, char *const argv[]);
int execvp(const char *file, char *const argv[]);
int execvpe(const char *file, char *const argv[],char *const envp[]);
</syntaxhighlight>
Spiegazione dei postfissi:
* l = elenco dei parametri passato tramite parametri a cardinalità variabile (variadic function)
* v = elenco dei parametri passato come array
* p = bisogna specificare il path completo dell'eseguibile
* e = bisogna specificare anche l'enviroment con cui verrà eseguito il programma. L'enviroment è una serie di variabili globali, tra cui il path. Il path è l'elenco dei percorsi dei programmi più usati.
Tutte queste funzioni alla fine sono solo delle interfacce per execve.
* '''Programmazione ad eventi'''
:E' un paradigma di programmazione dove il flusso del programma è determinato dal avverarsi di eventi. Il programmatore specifica il codice (Handlers) che deve essere eseguito al verificarsi di un certo evento. 
:System call che sono utili per far questo sono select,pselect,poll,ppoll,epoll.

== Lezione del 15 novembre 2016 ==
* '''Differenza tra select,poll,pselect,ppoll e epoll'''
:La poll a differenza della select richiede un array di strutture pollfd invece che una bitmask. Permette di specificare precisi eventi per cui stare in ascolto. 
:Le versioni con prefisso "p" implementano anche la gestione dei segnali. 
:L'epoll è linux only. E' moderna (2002) e fornisce un file dove leggere direttamente quali file descriptor sono stati modificati in modo da non dover scorrere tutta la lista.
* '''Dimostrazione della equivalenza di potere espressivo fra semafori e semafori binari.'''
:I semafori implementati per dimostrare l'equivalenza possono essere trovati a [[Esperimenti_con_semafori_e_monitor_in_C | questa pagina]].
* '''Definizione di Monitor.'''
Un monitor è un costrutto ad alto livello per la sincronizzazione pensato ispirandosi alla programmazione ad oggetti. 
E' una classe che incapsula la risorsa condivisa, la rende privata e permette di accedere a questa solo tramite metodi. Questi metodi implementano i meccanismi di sincronizzazione. 
Uno solo processo può essere al interno del monitor e avere accesso ai dati protetti da mutua esclusione. 
E' presente una coda di attesa per l'accesso al monitor. 
Definiamo inoltre delle variabili ''condition''. 
Gli unici metodi che possono essere chiamati su una condition sono wait e signal. Ogni condition ha una propria coda di attesa 
L'operazione wait sospende il chiamante e lo sposta nella coda di attesa della condition.
L'operazione signal risveglia un processo in attesa. Se non c'è nessun processo in attesa all'interno del monitor la signal fa entrare un eventuale processo in attesa di entrare nel monitor. Il chiamante di signal dopo aver risvegliato l'altro possibile processo deve mettersi in attesa per evitare che ci siano due processi in concorrenza al interno del monitor, ma invece di andare nella coda di attesa della condition viene messo in un ''urgent stack'' che ha più priorità rispetto alla coda esterna dei processi in attesa di entrare nel monitor. 
Ricapitolando le strutture dati per un monitor sono una coda esterna per l'accesso al monitor, una coda interna (non accessibile da fuori ma non dentro la mutua esclusione) per ogni variabile condizionale e l'urgent stack. 
* '''Implementazione dei Semafori tramite monitor.'''

== Lezione del 18 novembre 2016 ==
* '''File speciali a blocchi o a caratteri'''
: In Unix molte cose sono rappresentate come file. Per esempio i device come i terminali e le partizioni del disco sono file. Si chiamano ''file speciali'' ma non sono tanto differenti dai file comuni. Utilizzano anche gli stessi sistemi di protezione all'accesso. Si dividono i due categori:
:* File speciali a blocchi: utilizzati maggiormente dai sistemi di storage tipo hard-disk e CD-ROMs. Se per esempio il blocco è di 1024 bytes allora possiamo scrivere e leggere con tale granularità, cioè non potremo mai scrivere soltato 500 bytes ma dovremo scrivere, appunto a "blocchi".
:* File speciali a caratteri: utilizzati maggiormente per dispositivi di input-output tipo mouse,tastiera,terminali ecc.. permettono di lavorare con una granularità di 1 byte ma hanno un accesso sequenziale invece che diretto come i file a blocchi.
:Inoltre nei file speciali l'ampiezza è sostituita da 2 numeri, uno che indica il driver del dispositivo e l'altro le possibili parti del dispositivo, per esempio le partizioni.
* '''System call ioctl'''
: Ioctl serve per controllare dei device. Per esempio permette di fermare la testina di lettura del disco oppure far partire il motore del lettore CD. E' necessaria in quando si è voluto uniformare la lettura e scrittura di stream per tutti i device tramite le system call read/write ma chiaramente ogni dispositivo ha anche le sue diverse necessità e queste vengono soddisfatte da ioctl.
* '''Syscall'''
: Syscall è una funzione di libreria C che serve a chiamare system calls che non hanno una loro interfaccia per il linguaggi C. Per esempio getdents.
* '''System call e funzioni di libreria per directory'''
:Le directories sono sempre file ma si può fare l'accesso solo in lettura, per esempio per ottenere la lista di tutti i file e directory all'interno di quella directory. 
:getdents legge un file directory ed è la system call principale, tutte le funzioni di libreria C tipo opendir,readdir,readdir_r(per multithread) chiamano getdents. 
:Tutte queste funzioni lavorano con una struct dirent che rappresenta una directory entry. 
:Si può usare anche scandir che è reetrant (nessun problema di race condition) e invece di leggere un elemento della directory per volta ritorna direttamente un array di tutti gli element allocato dinamicamente (occorre ricordarsi di deallocare con free tutti gli elementi e l'array stesso).

== Lezione del 22 novembre 2016 ==

Problema dei filosofi a cena risolto con i monitor. Soluzione con le condizioni associate alle "bacchette" e con le condizioni associate ai filosofi.
discussione dei problemi di deadlock e starvation nell'implementazione tramite monitor.

Problema dei lettori e scrittori tramite monitor. Soluzione con privilegio ai lettori, agli scrittori e modifiche necessarie per la soluzione priva di starvation.

== Lezione del 25 novembre 2016 ==
[[Coding Contest]]

== Lezione del 29 novembre 2016 ==
* '''Implementazione dei monitor tramite semafori'''
:Un soluzione simile a quella vista a lezione può essere trovata [[Esperimenti_con_semafori_e_monitor_in_C#Monitor implementati con semafori | qui]].
* '''Introduzione al message passing'''
:E' un altro modo per fare programmazione concorrente alternativo alla memoria condivisa che abbiamo visto fin ora.
:Se i programmi non condividono memoria ma devono sincronizzarsi per lavorare assieme hanno bisogno di scambiarsi messaggi.
:Per l'indirizzamento serve un sistema di naming, come il pid dei processi.
:Due primitive: send e receive. Nella receive come indirizzo da chi ricevere si può mettere una wildcard in modo da riceve da tutti.
:Nella send invece occorre indicare l'identificativo del destinatario (se si ammettesse di poter inserire una wildcard si spedirebbero messaggi in broadcast/multicast. E' una problematica più complessa che viene trattata nei corsi di sistemi distribuiti).
:Lo scambio di messaggi può essere:
:* Sincrono: send bloccante e receive bloccante, senza memoria di supporto.
:* Asincrono: send non bloccante e receive bloccante, con memoria di supporto. I messaggi spediti rimangono in una coda (di ampiezza massima illimitata nel modello).
:* Completamente asincrono: send non bloccante e receive non bloccante. Poco utilizzato, il destinatario deve fare un polling per controllare se il messaggio è arrivato o no.
:Per dimostrare la stessa espressività dei metodi dobbiamo sempre creare delle librerie e non dobbiamo aggiungere nessun processo.
:La metodologia asincrona è espressiva almeno quanto quella sincrona mentre non è vero il contrario.
:Per creare un metodo sincrono con chiamate asincrone basta bloccare il programma finché non si riceve un acknowledgement.
:Invece per creare un metodo asincrono con chiamate sincrone bisogna aggiungere un processo e quindi questo dimostra che non sono equivalentemente espressive.
* '''Soluzioni di esercizi d'esame'''
** Problema della lavatrice
** Problema del ponte a senso unico

== Lezione del 2 dicembre 2016 ==
* '''Implementazione della libreria per message passing'''
:I sorgenti della implementazione possono essere trovati [[Esperimenti con message passing in C|qui]]
* '''I segnali'''
:I segnali sono un metodo di comunicazione tra processi utilizzato in UNIX.
:Ogni segnale è rappresentato da un numero. Per esempio "segmentation fault" è il numero 11.
:La system call kill() serve per inviare un segnale. signal() serve per definire l'handler, una funzione che viene eseguita quando il processo riceve uno specifico segnale.
:Ogni segnale ha il suo handler di default e tramite signal() noi sovrascriviamo il default handler.
* '''Permesso setuid'''
:Permette a dei programmi di eseguire operazioni che hanno bisogno dei permessi di root. L'attributo setUserId attivato vuol dire che il programma verrà eseguito con i privilegi del possessore del file piuttosto di quelli di chi lo esegue.
* '''Proposta di soluzione esercizio 4 del [[Coding Contest 25 novembre 2016]]'''

== Lezione del 6 dicembre 2016 ==

* Implementazione di un servizio di Message Passing Asincrono dato uno sincrono (con processo server).
* Implementazione di un servizio di Message Passing completamente asincrono dato uno sincrono.
* Analisi del potere espressivo dei servizi di message passing.

* kernel monolitici e microkernel
* macchine virtuali a livello di processo e a livello di sistema

I sorgenti degli esperimenti con il message passing sono in [http://www.cs.unibo.it/~renzo/so/tools/mp.extra.tgz questo file].

== Lezione del 9 dicembre 2016 ==

* Il problema della Cena dei filosofi con il message passing (asincrono)

* Buffer Limitato con message passing (asincrono).

== Lezione del 13 dicembre 2016 ==

La lezione TACE per malattia (influenza) del docente.

== Lezione del 16 dicembre 2016 ==
*'''Specifiche del progetto fase uno'''
Il documento delle specifiche può essere trovato [http://www.cs.unibo.it/~renzo/so/mikaboo/phase1.pdf qui].
:*List.h
:*Lista dei processi
:*Coda dei thread
:*Code dei messaggi
*'''Autotools'''
:Insieme di strumenti per la generazione automatica di Makefiles. 
:comando ''autoreconf'' per generale il file ''configure'' 
:''./configure'' per generare makefile.

== Lezione del 21 febbraio 2017 ==
'''Argomenti trattati:'''
* '''Visione a strati di un elaboratore'''
:Gli strati sono livelli di astrazione. Ogni strato deve "parlare" il linguaggio del livello sottostante e deve fornire un proprio linguaggio ai livelli superiori.
:Per esempio il sistema operativo parla l'ISA del livello hardware e fornisce alle applicazioni le system call. Il sistema operativo maschera il livello hardware in quanto fornisce la possibilità alle applicazioni di utilizzare istruzioni ISA ma non tutte, per ragioni di sicurezza.
* '''Componenti fondamentali di un sistema operativo'''
:A sua volta il sistema operativo può essere visto come un insieme di strati. Esistono sistemi operativi a singolo strato (come MS-DOS) e più strati (layered).
:Le parti principali in cui possiamo suddividere un sistema operativo sono:
:*Lo scheduler
:*Il memory manager
:*Il file system
:*L'I/O manager
:*Il networking manager
:Di questa lista, gli elementi assolutamente fondamentali per considera un programma un sistema operativo sono lo scheduler e una parte essenziale del memory e I/O manager.
:Il networking e file manager si appoggiano al I/O manager per svolgere i loro compiti.
*'''Bootstrap'''
:Letteralmente "mettersi in piedi tirandosi dai lacci degli stivali", nel senso di attivarsi senza aiuto esterno. All'accensione il computer legge da una ROM le prime istruzioni necessarie. Viene sempre letto dai primi settori della memoria di massa il bootloader. :Il bootloader (per esempio GRUB) conosce già molti filesystem, ma non abbastanza. Il bootloader carica un file system temporaneo apposito chiamato initrd per caricare i moduli necessari al kernel.
*'''Come rappresentiamo i processi'''
:Dobbiamo sia tener conto a che punto siamo arrivati nell'esecuzione del processo sia tener conto delle risorse di cui il processo è detentore.
:Utilizziamo la struttura ''Process Control Block'' (task_struct in linux) per i processi e "Thread Control Block" (task_struct in linux) per i thread.
:Process control block:
:*PID (Process ID)
:*PPID (Parent Process ID) per poter creare una gerarchia di processi
:*punti di accesso alla memoria (codice,dati,tabella di rilocazione,paginazione)
:*lista dei thread
:*owner (se il sistema è multiuser)
:*Risorse del processo
:*Coda dei messaggi per IPC (Inter-Process Communication)
:*accounting (tempo di esecuzione sia in modalità kernel sia in modalità user)
:*valore di ritorno del processo
:Thread control block:
:*TID (Thread ID)
:*stato del processore
:*call stack
:*ready/running/waiting
*'''Avvicendamento dei processi'''
:Definizione di avvicendamento: ''Successione prevista o regolata nel tempo, alternanza.''
:I context switch avvengono a seguito di trap/interrupt.
:Il ciclo di vita di un processo passa tra gli stati ''ready, running, waiting'' e infine ''term''.
:Lo scheduling (processo decisionale) può venire applicato nelle seguenti 4 situazioni:
:# Quando un processo passa dallo stato di running a quello di waiting
:# Quando un processo passa dallo stato di running a quello di ready
:# Quando un processo passa dallo stato di waiting a quello di ready
:# Quando un processo passa dallo stato di running a quello di term
:Se lo scheduling avviene solo nella situazione 1 e 4 allora si utilizza un metodo non preemptive. Dal momento che la CPU è allocata a un processo questo la detiene finchè non termina o entra di sua spontanea volontà in stato di waiting. La CPU non può decidere di far aspettare un processo spostandolo temporaneamente nella coda dei processi ready. Questo sistema era utilizzato da vecchi sistemi operativi come Windows 3.x e dalle versione di Mac OS prima della versione X.
:Nel preemptive scheduling invece la CPU può decidere di sospendere un processo, questo può creare race condition ma anche un sistema più equo di distribuzione delle risorse. Le race condition vengono risolte con i metodi che abbiamo visto nel primo semestre.
'

== Lezione del 23 febbraio 2017 ==

'''System call'''

Abbiamo analizzato le system call che erano già presenti nella [http://man.cat-v.org/unix-6th/2/ versione 6 di Unix] (1975). 
Le abbiamo poi confrontate con quelle attuali del [[Il_%27%27catalogo%27%27_delle_System_Call]].

'''Shell Scripting'''

Gli script vengono utilizzati per lanciare un demone, guardare i processi, etc.
Anche l'amministrazione di sistema avviene tramite scripting. Ad esempio, dopo il boot, il processo init avvia le funzionalità di sistema tramite script.

Unix unifica l'idea di script con quella di shell.
La shell è un processo che interagisce con l'utente. In Unix la novità introdotta è rappresentata dalla presenza di un linguaggio che riguarda i comandi, utile per scrivere gli script per la shell.

Come indichiamo quale shell usare? Scrivendo nella prima riga #! seguito dal path e dal nome della shell. Il kernel prende ciò che è scritto nella prima riga e lo esegue per interpretare lo script.
Nell'esempio sottostante Script è un commento perchè è preceduto da #.

ESEMPIO

#!/bin/bash
#Script

echo "Hello World!"

Per scrivere script abbiamo bisogno di variabili. Nelle shell queste possono essere di 2 tipi:

- Locali: viste solo dalla shell, non perturbano comportamento dei processi.

- D'ambiente: recepita dai comandi come ambiente.

'''ASSEGNAMENTO E VARIABILI'''

ESEMPIO 1

a=2 /* Non devono esserci spazi!!! a = 2 doesn't work */
echo $a /* Stampa 2 */
echo ${a}a /* Stampa 2a */

ESEMPIO 2 - Nuova shell

bash /* Apro nuova shell */
echo $a /* Stamperà una riga vuota perchè la var. a non è locale della nuova shell */
exit /* chiudo nuova shell */

ESEMPIO 3 - Esportare variabile locale

export a /* La var. a diventa variabile d'ambiente */
bash
echo $a /* Ora possiamo chiamare la var. a perchè è diventata d'ambiente */

ESEMPIO 4 - csh

csh in molti casi dovrebbe già essere installato di default.
Se non è così è possibile installarlo eseguendo

sudo apt-get install csh

csh /* Apro cshell, noterete il simbolo di percentuale % a inizio riga di comando */
set a=42 /* assegnamento */
csh /* apro nuova shell */
echo $a /* non possiamo chiamare a(42) perchè locale alla prima shell, viene chiamata a d'ambiente se presente */
exit
setenv a 42 /* Per creare una variabile d'ambiente, da notare la mancanza di = */
csh
echo $a

'''ARGOMENTI'''

Negli script possiamo avere degli argomenti.
Vengono visti come $1, ..., $9, ${10}, etc.
$* indica tutti gli argomenti

ESEMPIO 1
#!/bin/bash
echo $* /* Richiama tutti gli argomenti */
echo $1 $2 /* Richiama solo i primi due argomenti */
shift /* Sposta la riga di comando degli argomenti di una posizione verso sx */
echo $*

Una volta salvato il file con estensione .sh, eseguire da terminale:
chmod +x nomefile.sh
./nomefile.sh arg1 arg2 ...

Se passiamo come argomenti: uno due tre quattro,
l'output sarà:
uno due tre quattro
uno due
due tre quattro

A volte dobbiamo proteggere dei caratteri. Alcuni di essi possono essere delle wildcard. Ci sono 3 modi per proteggerli:
\*
'*'
"*"

Analizziamone le differenze tramite un esempio.

ESEMPIO 1

echo \* // OUTPUT: *
echo '*$a' // OUTPUT: *$a
echo "*$a" // OUTPUT: *2

Nel primo caso l'escape vale solo per *. Nel secondo caso vale per tutta la stringa. Nel terzo caso vale per * e richiama la variabile.

ESEMPIO 2
echo ab // OUTPUT: ab
echo "ab" //OUTPUT: ab

echo a b //OUTPUT: ab <-- non rileva gli spazi
echo "a b" //OUTPUT: a b

== Lezione del 28 febbraio 2017 ==
'''Argomenti trattati''':
* '''Ciclo di vita di un kernel'''
: Dopo l'inizializzazione (Creazione di code, rilevazione di device, ecc..) si crea a "mano" il primo processo.
: L'esecuzione dello scheduler si alterna a quella dei processi. Quando un processo utente viene eseguito il kernel non ha più il controllo del flusso e gli viene restituito solo quando avviene un interrupt/trap.
* '''Parametri di valutazione di un algoritmo di scheduling'''
** % Utilizzo CPU: Bisogna cercare di tener utilizzata il processore il più possibile riducendo i momenti di inutilizzo (idle).
** Produttività (Throughput) Numero di processi completati per unità di tempo
** Tempo totale (turnaround time) Tempo totale impiegato dall'esecuzione del processo al completamente. Tiene conto del tempo speso in attesa oltre al tempo in esecuzione.
** Tempo di risposta: Tempo prima che un primo output venga generato dal momento in cui il processo viene eseguito. In un sistema interattivo è importante per non dare all'utente l'idea di malfunzionamento.
** Tempo di attesa. Non aspettando l'I/O ma bensì tempo speso nella ready queue.
* '''Processi CPU Bound e I/O Bound'''
:: I processi si possono dividere in queste due categorie. I processi che utilizzano il processore per tempi più lunghi (per esempio quelli di calcolo scientifico) si chiamano CPU Bound mentre quelli che richiedono spesso interazioni e si fermano ad aspettare l'I/O si chiamano I/O Bound. Algoritmi di scheduling differenti possono favorire o sfavorire una delle due categorie. L'obbiettivo e trovare un algoritmo che sia ottimale per tutti i processi.
* '''Algoritmi di scheduling'''
** First come first served
:: Lo scheduler implementa una semplice coda dei processi che hanno richiesto l'esecuzione. E' semplice da capire e creare ma il tempo medio di attesa per un processo può essere lungo. Dipende molto dall'ordine in cui vengono avvicendati processi CPU bound e I/O Bound. Un processo CPU bound può creare un ''effetto convoglio'' e far dipendere il tempo di attesa di altri processi che sono I/O bound al suo tempo di esecuzione. Questo algoritmo non è quindi equo.
:* Shortest job first
:: Forse più correttamente nominato algoritmo ''shortest next CPU burst''. Ad ogni processo viene associato il suo tempo di esecuzione e viene scelto dalla ready queue sempre il processo con il tempo più basso. Per determinare il tempo di esecuzione a priori si utilizza una media esponenziale dei tempi di esecuzione dello stesso processo nel passato. [[File:Media_esponenziale.png]] ''t'' sono le misurazioni recenti mentre 'tau' sono la storia più ''remota''. Il parametro alfa determina quanto la media esponenziale sia basata sulla storia recente o su quella passata.
:* Shortest remaining time first
:: SJF può essere preemptive oppure no. Nel caso preemptive prende il nome di ''Shortest remaining time first''. Se un processo A è in esecuzione e arriva un'altro processo B con tempo di esecuzione minore allora A viene fermato e viene eseguito B. La priorità di A nella coda è ora il tempo stimato rimanente.
:* Round robin
:: E' definita un unità di tempo, di solito tra i 10 e i 100 millisecondi, e ogni processo ha un tempo massimo di esecuzione pari a questa unità. I processi vengono avvicendati a turno in una coda. Un processo termina l'esecuzione o per sua volontà (il tempo rimasto del quanto di tempo non è considerato) oppure perchè è scattato l'interval timer. Nell'ultimo caso il processo viene inserito in coda come se fosse un processo appena arrivato. La performance di questo algoritmo dipendono molto da che tipi di processi si gestiscono e dalla dimensione dell'unita di tempo. Se questa è larga allora l'algoritmo è più simile a FCFS mentre un'unita di tempo piccola porta a più context switch e quindi a più overhead. L'unità di tempo andrebbe decisa in proporzione al tempo di context switch.
:* Scheduling a priorità
:: Ad ogni processo è assegnata una priorità che si riflette nella priorità che ha il processo nella ready queue.
:: La priorità di un processo può essere influenzata da fattori interni (come i requisiti di memoria) o esterni al sistema operativo (come ''l'importanza'' di un processo). L'algoritmo può essere non preemptive o premtive, nel caso in cui interrompa il processo attuale se arriva un processo con più priorità.
:: L'SJF può essere visto come un caso particolare di scheduling a priorità, in cui la priorità e appunto inversamente proporzionale al tempo di esecuzione.
:: Un problema dello scheduling a priorità è la starvation, che può essere risolta con il meccanismo di ''aging'' in cui un processo aumenta di priorità proporzionalmente al tempo cui rimane nella ready queue.
:* Scheduler multilivello
:: Questo è lo scheduler più completo in quanto divide i processi in gruppi e utilizza differenti algoritmi per ogni gruppo.
:: Una tipica suddivisione è quella di processi foreground e background, rispettivamente I/O bound e CPU bound. Per ogni gruppo viene creata una coda apposita.

== Lezione del 2 marzo 2017 ==

'''Shell Scripting'''

'$' seguito da caratteri esegue una sostituzione, questa può essere:

'''ESEMPIO 1 (contenuto)'''

echo $SHELL

echo $USER

'''ESEMPIO 2 (comando)'''

echo $ls

'''ESEMPIO 2.1'''

du -s $(ls -d *es) //du -s prende come input l'output del comando compreso tra parentesi tonde

'''ESEMPIO 3 (wildcard)'''

echo * // tutti file/dir
echo *es // file/dir che terminanon con es
echo *[lg]es // file/dir che terminanon con les/ges
echo ????? // file/dir con 5 caratteri

Queste wildcard servono per poter individuare insiemi di file in un colpo solo.

'''ESEMPIO 4 ($ come sintassi riconosciuta da grep)'''

grep '>$' *.c // trova tutte le linee che terminano con '>' all'interno dei file .c

'''ESEMPIO 5 (PID)'''

echo $$ // restituisce PID dello script nel quale viene eseguito

'''ESEMPIO 6a'''

echo $1 $2 $3 >/tmp/tmpscript //scrive i 3 argomenti in tmpscript

cat /tmp/tmpscript //lettura tmpscript
rm -f /tmp/tmpscript //rimozione tmpscript

Se cerchiamo di lanciare quasi contemporaneamente lo script dell'esempio 6 in due shell differenti, lo script non funziona perchè lavorano sullo stesso file. Possiamo quindi ricorrere all'utilizzo di $$.

'''ESEMPIO 6b'''

echo $1 $2 $3 >/tmp/tmpscript$$

sleep 3 //in modo da poter lanciare lo script in un'altra shell
cat /tmp/tmpscript$$
rm -f /tmp/tmpscript$$

'''ESEMPIO 7'''
grep bash myscript.sh >& dev/null //ridireziono l'output di grep sul "null device"
echo $? //restituisce 0 se il comando precedente è stato eseguito correttamente, 1 altrimenti

'''Gli operatori >> e <<'''

>> è simile a > ma scrive alla fine del file invece che all'inizio. 
<< serve invece per inserire l'input di un comando direttamente nello script, come mostrato nel successivo esempio della mail.

'''ESEMPIO 8 (script per inviare mail)'''

#!/bin/bash

mail $1 << ENDOFMESSAGE
ciao $1 questa è una mail di prova
ENDOFMESSAGE //etichetta usata per indicare il termine del messaggio

Con

echo $1; echo $2; ls

raggruppiamo una sequenza di comandi sulla stessa riga

'''ESEMPIO 9((|| &&)'''

Gli operatori || e && possono essere utilizzati per processare più comandi consecutivamente.

command || die

gcc -o hwx hw.c && ./hwx

'''ESEMPIO 10 (sottoshell)'''

Una lista di comandi all'interno di () viene eseguita in una sottoshell. Le variabili all'interno della sottoshell non sono visibili al di fuori del blocco di codice nella sottoshell. Sono variabili locali.

(cd subdir; ls) //eseguo un comando in un'altra directory

'''Pushd e popd'''

Simili al comando ''cd'' ma pushd inserisce i percorsi visitati in una pila e tramite popd e possibile ripercorrere a ritroso le directory visitate.

'''ESEMPIO 11 (background jobs)
ping google.com & //esegue ping in background
jobs //mostra la lista dei jobs in esecuzione
//poniamo che l'output di jobs sia "[1]+ In esecuzione ping google.com &"
kill -9 %1 //termina il processo con identificatore 1
''bg'' repristina un processo fermato con CTRL+Z. 
''fg'' riporta in primo piano un processo mandato in background.

'''test e type'''

''test'' serve a comparare valori e controllare il tipo dei file. 
la sintassi ''[]'' è un alias di test.
if [ $$ -eq '10853' ] ; then echo "il processo corrente ha pid 10853"; else echo "il processo corrente non ha pid 10853"; fi;
//che è equivalente a
if test $$ -eq '10853'; then echo "il processo corrente ha pid 10853"; else echo "il processo corrente non ha pid 10853"; fi;
''type'' invece mostra l'origine di un comando, se sono integrati nella shell oppure è un programma a parte.

'''Switch'''
Sintassi degli switch in bash.
case expression in
pattern1 )
statements ;;
pattern2 )
statements ;;
...
esac
'''Comando cron''' 
''cron'' serve per eseguire operazioni pianificate. Gli script in /etc/init.d vengono eseguiti automaticamente da cron.

'''xarg''' 
xarg permette di eseguire un comando passandogli come parametri i valori letti da standard input.

'''uniq''' 
uniq può essere usato per trovare e eliminare righe duplicate.

'''wc''' 
''wc'' crea il ''word count'' di un file. Non conta solo le parole ma anche i caratteri e le righe.

'''diff e patch''' 
Il comando ''diff'' può essere utilizzato per mostrare le differenze tra due file testuali. E' utilizzato internamente da git. 
Patch serve per applicare un ''diff file'' a un altro file in modo da aggiornarlo.

== Lezione del 7 marzo 2017 ==
Una risorsa è ogni elemento utile all'elaborazione.
* '''Classificazione di risorse'''
** '''Fisiche e logiche'''
::Esempi:
::CPU, memoria e dispositivi sono risorse ''fisiche''.
::file, strutture dati, critical section sono risorse ''logiche''.
:* '''Fungibili'''
::Una risorsa è fungibile se è uguale prendere un bene o un'altro se sono dello stesso tipo. Richiedere un area di memoria o un altra è indifferente se tutte e due soddisfano i requisiti del processo. Richiedere file o dispositivi differenti invece cambia.
:* '''Assegnazione statica o dinamica'''
::L'assegnazione statica prevede che una risorsa sia monopolio di un processo.
:* '''Accetta richieste multiple o solo singole'''
:: Se può ricevere richieste d'uso da più processi e memorizzare/servire contemporaneamente le richieste oppure no.
:* '''condivisibili e non condivisibili'''
:: Un file in lettura è una risorsa condivisibile, più processi possono accedere contemporaneamente. Un file in scrittura invece è una risorsa non condivisibile perché potrebbe capitare una race condition.
:* '''bloccante e non bloccante'''
::Se l'accesso alla risorsa implica dei tempi di attesa relativamente lunghi al processo, la risorsa è da considerarsi bloccante.
:* '''prelasciabile o non prelasciabile'''
::Il processo può rilasciare in qualsiasi momento la risorsa e permetterne l'uso ad un altro processo? Una stampante e un esempio di rirosa non prelasciabile.
* '''Deadlock'''
:Un deadlock può avvenire in presenza di risorse bloccanti, non condivisibili, non prerilasciabili e con una situazione di attesa circolare.
:* '''detection: grafo di Holt '''
::I grafi di allocazione delle risorse, introdotti da Holt nel 1972 sono un buon modo per descrivere lo stato di un sistema e prevedere possibili deadlock. Ogni nodo rappresenta una risorsa o un processo. Di solito le risorse sono rappresentate da quadrati e i processi da cerchi. Un arco da un processo a una risorsa significa che quel processo ha richiesto un'istanza della risorsa. Un arco da una risorsa a un processo vuol dire che un'istanza di quella risorsa è stata assegnata al processo. 
::* ''' teorema dei cicli in grafi di Holt con un solo tipo di risorsa
:::Se il grafo non contiene cicli allora di sicuro non possono esserci deadlock.
:::Se il grafo contiene un ciclo allora può esserci un deadlock.
:::Se le risorse coinvolte in un ciclo hanno solo un'istanza o ogni loro istanza e coinvolta in un ciclo allora c'è di sicuro un deadlock.
:::Questo tecnica di permette di analizzare uno stato ''attuale'' di un sistema, ma dobbiamo trovare un modo per prevedere lo stato ''futuro'' del sistema e quindi prevedere i deadlock.
::* '''processo di riduzione
:::Per vedere lo stato di un sistema futuro possiamo usare un processo di riduzione del grafo di allocazione delle risorse.
:::Se una risorsa allocata a un processo può essere data dopo un certo periodo a un altro processo che l'ha richiesta allora si può fare una riduzione. Una riduzione consiste nell'eliminare un arco risorsa-processo perchè quel processo ha finito di utilizzare la risorsa oppure è stata prerilasciata e invertire un arco processo-risorsa di un processo che aveva richiesto la risorsa in un arco risorsa-processo.
:::Se un grafo può essere ridotto per tutti i suoi processi allora non può esserci deadlock.
:::Il problema di questo metodo/algoritmo è che nel momento che deallochiamo una risorsa a un processo e più processi avevano richiesto quella risorsa come scegliamo deterministicamente a quale processo assegnare la risorsa? Dovremmo provare tutti i casi per accertarsi che non si crei deadlock, ciò significa fare backtrack e perdere la polinomialità dell'algoritmo.
::* '''definizione di Knot
:::Il Knot è una caratteristica di un grafo che si verifica velocemente e permette di determinare possibili deadlock.
:::Un knot è un insieme di nodi in cui, per ogni nodo del knot, tutti e solo i nodi del knot sono raggiungibili da quel nodo.
:::Un knot è una condizione sufficiente ma non necessaria per i deadlock. Ciò vuol dire che possono capitare deadlock anche senza la presenta di un knot.
::* '''teorema dei knot nei grafi di Holt con più tipi di risorse
:* '''prevention'''
::Se il sistema cerca di non far verificare almeno una delle condizioni necessarie al deadlock allora questo non si verificherà mai.
::Questo però comporta anche sottoutilizzo delle risorse del sistema.
:* '''avoidance'''
::*'''Condizione di safety'''
:::Un sistema è in una condizione di safety se esiste una safe sequence.
:::Una safe sequence è una sequenza di processi dove per ogni richiesta di risorse di un processo questa richiesta può essere soddisfatta con le richieste disponibili al momento più tutte le risorse allocate precedentemente ai precedenti processi della sequenza.
:::Finchè c'è safety non possono verificarsi deadlock. In una situazione unsafe non è detto che capiti deadlock, ma è possibile.
::*'''algoritmo del Banchiere (mono e multivaluta).
:::L'algoritmo del banchiere si basa sul fatto che una banca non dovrebbe mai rimanere senza denaro da prestare ai clienti.
:::Vengono mantenute varie strutture dati come il capitale iniziale della banca, quanto è disponibile in cassa, quanto è stato prestato ad ogni cliente e quanto si può ancora prestare ad ogni cliente (in base al ''credito'' che ogni cliente ha).
:::La condizione di safety è data dalla condizione che bisogna mantenere almeno uno dei clienti soddisfacibile cioè che il denaro in cassa sia maggiore del possibile richiesta di prestito di almeno un cliente.
:::Se questa condizione non si verificasse alloca il banchiere deve aspettare che un cliente restituisca il prestito.
:::In caso di più valute (yen, dollari, euro, ...) che rappresentano i tipi diversi di risorse del sistema. Tutte le strutture dati aumentano di una dimensione, per esempio il denaro iniziale diventa un vettore.
::Teorema: il processo di controllo di safety non ha necessita' di backtrack.
:* '''Tecnica dell'ostrica/struzzo'''
::Un altro modo per gestire i deadlock e quello di ignorarli completamente.
::La maggior parte dei sistemi operativi utilizza questo metodo.
::Soprattuto in sistemi in cui è statisticamente determinato che i deadlock si verificano poco frequentemente i sistemi di prevenzione e avoidance costituirebbero un overhead troppo elevato.
::Sta allora alle singole applicazioni evitare di crearli.

== Lezione del 9 marzo 2017 ==

* awk
* phase2: prime fasi del boot
* python: presentazione del linguaggio ed analisi delle caratteristiche

== Lezione del 14 marzo 2017 ==
'''Gestione della memoria'''
* Binding a tempo di esecuzione, compilazione o esecuzione
* Memory Management Unit (MMU)
* Allocazione statica o dinamica
* Allocazione continua o non contigua
* Metodo delle partizioni fisse
: Problema della frammentazione interna.
* Metodo delle partizioni variabili
:Problema della frammentazione esterna.
:* Algoritmi di scelta dell'area di allocazione
:** First fit
:** Best fit
:** Worst fit
:** Next fit
:* Paginazione
:* Segmentazione
:* Memoria virtuale

== Lezione del 16 marzo 2017 ==
* '''Progetto phase2''': analisi del manuale di uARM
* '''Python''': funzioni, oop, @memoize, @trace

== Lezione del 21 marzo 2017 ==

La lezione del 21 marzo tace per impegno del docente.

== Lezione del 23 marzo 2017 ==
'''Memoria virtuale''': 
'''Algoritmi di paginazione:'''
Quando avviene un page fault serve un algoritmo per trovare la pagina "meno utile" in memoria a cui sostituire la pagina richiesta.
* '''FIFO''' viene sostituita la pagina che da più tempo è in memoria
* '''LFU''' ''Least Frequently Used'' contando il numero di richieste alla pagina possiamo calcolare quali sono le pagine più richieste e tenere solo quelle in memoria. Il problema è che una pagina potrebbe essere richiesta molto in una fase iniziale di un processo, quindi avere un rank elevato, però poi non essere più utilizzata. Una soluzione a questo problema è quella di shiftare a destra di 1 i bit del contatore degli utilizzi a intervalli regolari, ponendo questo in un decadimento esponenziale.
* '''LRU''' ''Least Recently Used'' si sostituisce la pagina che non è stata utilizzata da più tempo.
* '''Algoritmo ottimo''' algoritmo teorico utile per fare ''benchmark'' degli altri algoritmi. Se conosciamo a priori la ''reference string'' una sequenza che indica quali saranno le richieste delle pagine nel futuro, possiamo sostituire le pagine che per più tempo non saranno richieste, riducendo al minimo i page fault.
'''Anomalia di Belady'''
Abbiamo dimostrato che l'algoritmo FIFO all'aumentare della memoria può peggiorare di performance.

== Lezione del 28 marzo 2017 ==
'''Algoritmo second chance o dell'orologio''' 
'''Linking statico''' 
'''Loading dinamico''' 
'''Memoria secondaria''' 
'''Algoritmi di scheduling delle seek''' 
*'''FIFO'''
*'''SSF'''
*'''c-look'''

== Lezione del 30 marzo 2017 ==
'''Discussione sulle specifiche del progetto''' 
:Creazione pagina [[Specifiche_phase_2_2016/17]]
'''Python standard library'''
* libreria sys: Permette di prendere parametri da linea di comando. Si utilizza ''sys.argv''.
* libreria os: Permette di navigare nella gerarchia di directory con ''os.walk''.

== Lezione del 4 aprile 2017 ==
'''RAID''' 
(Redundant Array Inexpensive/Independent Disks)

l’idea principale nasce per ottenere maggiori performance (raid 0 ed 1), non maggiore affidabilità (raid 4 e 5).

* RAID0 (Striping): i dischi sono posti in sequenza.Vengono create le stripe, sequenze di bit che sono posti su n dischi sequenzialmente. Lo striping può essere a vari livelli, a livello di bit, di byte, di settore o di blocco. Quello più utilizzato e il livello di blocco. Cioè per scrivere un file che è composto da più blocchi si suddividono i blocchi in più dischi. Attenzione, file piccoli potrebbero sostare su una sola stripe, quindi su un solo disco.
:Il miglioramento di performance si paga in maggiore faultness. dipende dal costo dei dati salvati.

* RAID1 (mirroring): ogni disco ospita la copia dei dati. doppia velocità in lettura (teoricamente). Stessa velocita di scrittura.
: Size = ½ readSpeed = N wSpeed = ½ N FT = 1
* RAID10 = 1+0 striping su 2 mirror.

* RAID 2-3 (deprecated):Agisce sui singoli blocchi i dati vengono salvati in maniera sincrona con meccanismi di parità (hoffman per correzione di errori nel RAID2, ciclica per RAID3).

* RAID4: usa dischi normali, non agisce su singoli blocchi ma su stripe ampi.

parityMap = S0 XOR S1 XOR S2 XOR S3 (in caso di 4+1 dischi).

nel caso si rompa S4, i dati non avranno problemi. Se si rompesse un qualunque dei primi 4 dischi, basterà effettuare lo XOR degli altri e copiare tali dati su un nuovo HD.

S1 rotto.
new_S1 = S0 XOR S2 XOR S3 XOR P0123
Sopporta una sola rottura.

Per aggiornare il disco di parità in caso di modifica a S2 (chiamato ora S2’)

P0123 = P0123 XOR S2 XOR S2’.
il primo xor toglie il valore da P0123 di S2, il secondo XOR aggiunge il valore S2’.
in questo modo, aggiorno solo 2 dischi, e uso gli stessi in lettura per ricalcolare la parità.

Le parità ciclano su tutti i dischi. Esistono controller che effettuano RAID5, oppure e’ possibile ottenere le funzionalità raid via sistema operativo.

* RAID5:
:Senza fault
:Size = N-1/N, rspeed=(N-1), wspeed=(N-2), FT=1

I dischi RAID soffrono alquanto in caso di terremoti.

'''File System:''' 
Servizio per dare una interfaccia più comoda e generale per l’accesso alla memoria secondaria.

Nasce come informatizzazione delle pratiche di ufficio. le pratiche sono salvate in folders, fascicoli, poste poi nelle directories. come visualizzo questa struttura per l’utente? E ad i programmatori? come viene implementato?

Nasce l’idea di “aprire” i file. Nell'accedere da un programma ad il file-system (operazione non banale) si preferisce chiamare un’operazione di apertura, e utilizzare un descrittore al file per agire sul file richiesto.

La struttura di file/folder/directories possono inoltre supportare le astrazioni di condivisione e proprieta’.
Tutti i controlli sono effettuati sono in fase di apertura (in modo da migliorare le performance).

Quali attributi caratterizzano un file?
<ul>
<li>Name,</li>
<li>Type,</li>
<li>Location,</li>
<li>Size,</li>
<li>Ownership,</li>
<li>Protection,</li>
<li>Time stamp</li>
</ul>
UNIX opta per una scelta minimalista. Tutti i file sono stringhe di byte.
AFS (Apple) da un tag di tipo e di creator per ogni file

maggiore e’ il numero di tipi di file, maggiore supporto per essi, ma piu’ codice nel kernel.
I suffissi possono indicare ad altri programmi il tipo.

Semantica della coerenza vs Semantica delle sessioni (Andrew File System)

Per quali motivo vengono create le partizioni?
/var andrebbe in una nuova partizione per un fattore di sicurezza.

Cosa c’e’ effettivamente sul disco? Una sequenza di blocchi, il cui primo (boot block) ha spazio per il bootloader e la tabella delle partizioni (MBR), con 4 elementi. 4 record che indicano dove ogni partizione inizia e finisce. Si possono usare partizioni estese, usando le prime 3 e nella quarta tutto il resto.

Ogni partizione ha all'inizio un BootRecord.
L’ultima partizione contiene nel BootRecord le altre partizioni.
GBT consente di avere un numero arbitrario di partizioni.

Raizer FS,

Read only file systems.

Initrd, ISO9660.

Quando si costruisce l’immagine, in realtà si sta creando il file-system ISO9660.

Come gestire invece file che possono cambiare?
Allocazione indicizzata (a lista): creo un (o vari) blocco/i degli indici che punta ad i blocchi dati.
l’accesso diretto cresce come il logaritmo dell’ampiezza.
Allocazione concatenata (ad albero): (in fondo al blocco indico il successivo). Gestisce bene la dinamicità. Non piace perché’ non é per nulla efficiente l’accesso diretto.

Quali allocazioni usano i filesystem reali oggi?

fat: concatenata. I blocchi tengono solo i dati, esiste una file allocation table (vettore) che indica il prossimo blocco. I puntatori sono tutti vicini e quindi ponendo il vettore in cache, abbiamo disponibili diversi puntatori.

BerkleyFastFileSystem (progenitore dei EXT4…) usano allocazione indicizzata. Nasce per garantire performance ad i file piccoli. Nel descrittore del file (iNode) avra’ N (13 attualmente) puntatori. Uno, il numero 10, ad i blocchi, uno (11) indiretto alla tabella, uno (12) come duplice indiretto e il 13esimo come triplice indiretto.

I file hanno quindi una lunghezza massima. EX4 pero’ risolve indicizzando non i singoli blocchi ma le serie.

Gestione spazio libero

nella struttura indicizzata serve una struttura per tenere conto degli spazi liberi. Si puo’ usare una bitmap per tenere la contabilità degli spazi liberi e quelli utilizzati.

== Lezione del 6 aprile 2017 ==

File System. Ext2 e VFAT. Sicurezza, principi generali.

== Lezione del 11 aprile 2017 ==

Sicurezza: crittografia (chiave pubblica/chiave segreta) autorizzazione autenticazione firma elettronica.
Virus Worm Cavalli di Troia.

Attacchi buffer overflow e toctou.

== Lezione del 20 aprile 2017 ==

(tace per impossibilita' del docente)

== Lezione del 27 aprile 2017 ==

P2test (prestest2).

DIscussione specifiche.

== Lezione del 2 maggio 2017 ==
== Lezione del 4 maggio 2017 ==
* Discussione su proposta da parte degli studenti di modifiche al test di progetto
* Soluzione all'esercizio C1 del 2014-06-16 (Monitor)
* Soluzione all'esercizio 1 del [[http://www.cs.unibo.it/~renzo/so/pratiche/2015.05.29.pdf 2016-05-20]] ( C )
* Soluzione all'esercizio 2 del 2008-06-13 (Dimostrazione algoritmo di rimpiazzamento a stack)
* Soluzione all'esercizio 1 del [[http://www.cs.unibo.it/~renzo/so/compiti/2013.07.19.tot.pdf 2013-07-19]] (Monitor)

== Lezione del 9 maggio 2017 ==
*Esercizio 2 prova teorica 2014.09.24
*Esercizio g.1 prova teorica 2013.07.19
*Esercizio c1 e c2 prova teorica 2015.01.20(2014.01.20)
*Esercizio c2 2013.05.30

== Lezione del 11 maggio 2017 ==
== Lezione del 16 maggio 2017 ==
* Chiarimenti su svolgimento esame
* Commenti su recenti eventi (WannaCry)
* Visione di programma python per costruzione di stringhe palindrome con monitor
* Correzione esercizio g2 prova teorica 20170209
* Correzione esercizio 1 [[Prova pratica 2016.09.13]]
* Esercizio c2 prova teorica 20140122

== Lezione del 18 maggio 2017 ==

Prova teorica 2014.06.03

2017-06-14T12:35:33Z

FedericoB: Aggiunta soluzione

Testo: [http://www.cs.unibo.it/~renzo/so/compiti/2014.06.03.tot.pdf]

== Esercizio c.2 ==

Siano dati 4 processi:
<syntaxhighlight lang="Python">
prchar=”IATL”
Process i: i=range(4)
while True:
sync(i)
print(prchar[i])
</syntaxhighlight>

Scrivere la funzione sync in modo che in un sistema di processi a memoria privata, usando message passing asincrono, l'unico
output possibile sia la stringa di lunghezza infinita: “ITALIAITALIAITALIA....”

===Soluzione di S.G===

Solo il processo 2 (lettera T) permette di iniziare la sincronizzazione dei processi.

Oltre al processo 2 anche il processo 1 (lettera A) permette di riavviare la sequenza.

''Nella descrizione di seguito chiameremo T il processo incaricato a stampare tale lettera, e cosi anche per gli altri.''

<syntaxhighlight lang="Python">
def sync(i):
if i == 0: # Processo 0 (processo I)
mittente = recv(*) # Aspetto un messaggio da T, L o A
if mittente == 2 or mittente == 1: # Se il mittente è il processo T o A (avvio o riavvio sequenza)
send(2, 0) # Invio un messaggio al processo T

elif mittente == 3: # Se il mittente è il processo L
send(1, 0) # Invio un messaggio al processo A

elif i == 1: # Processo 1 (processo A)
mittente = recv(*) # Aspetto un messaggio dal processo T o I
if mittente == 0: # Se il mittente è il processo I
send(0, 1) # Invio un messaggio al processo I (riavvio la sequenza)
elif mittente == 2: # Se il mittente è il processo T
send(3, 1) # Invio un messaggio al processo L

elif i == 2: # Processo 2 (processo T)
send (0, 2) # Invio un messaggio al processo I (Avvia la sequenza)
mittente = recv(0) # Aspetto un messaggio dal processo I
if mittente == 0: # Se il mittente è il processo I
send(1, 2) # Invio un messaggio al processo A

elif i == 3: # Processo 3 (processo L)
mittente = recv(1) # Aspetto un messaggio dal processo A
if mittente == 1: # Se il mittente è il processo A
send(0, 3) # Invio un messaggio al processo I
</syntaxhighlight>
Una volta avviato T invierà un messaggio a I e si bloccherà in attesa di I.

Il processo I in attesa riceverà un messaggio da T, allora sbloccherà T e stamperà I.

A questo punto il processo T invierà un messaggio ad A, e stamperà T.

A aspetterà messaggi da più mittenti, in questo caso riceverà un messaggio da T, invierà un messaggio ad L e stamperà A.

L aspetterà il messaggio da A che appena ricevuto invierà un messaggio ad I, e stamperà L.

Il processo I in attesa, riceverà un messaggio da L sbloccandosi invierà un messaggio ad A e stamperà I.

A ancora una volta in attesa, riceverà un messaggio da I, risponderà ad I e stamperà A.

I riceverà un messaggio da A, e riavvierà la sequenza.
[[User:S.G|S.G]] ([[User talk:S.G|talk]]) 10:35, 4 December 2016 (CET)

===Soluzione di FedericoB===
Penso che la soluzione di S.G. sia sbagliata in quanto appena si fa una send un processo bloccato su una receive viene sbloccato. Quindi per esempio verrà stampato T prima di I. L'idea è di sbloccare T alla seconda chiamata di sync(0). Per sapere il numero della chiamata si può utilizzare un contatore statico, che mantiene il suo valore tra le chiamate di funzione e viene inizializzata a 0.
<source lang="python">
sync(i)
if i==0: #processo "I"
if (count=1):
send(2)
recv(3)
elif: (count=2)
send(1)
recv(1)
count = 0
elif i==1: #processo "A"
if (count==0)
recv(2)
elif (count=1):
send(3)
recv(0)
elif: (count=2)
send(0)
recv(2)
count=0
elif i==2: #processo "T"
if (count==0)
recv(0)
elif (count=1):
send(1)
recv(0)
count=0
elif i==3: #processo "L"
if (count==0)
recv(1)
elif (count=1):
send(0)
recv(1)
count=0
count++
</source>
Sequenzialemente le chiamate sono in quest'ordine
<source lang="text">
sync(0) non fa nulla
print(I)
sync(0) count=1 manda messaggio a T e si bloccherà in attesa di un messaggio da L
sync(2) count=0 aspetta messaggio da I
print(T)
sync(2) count = 1 manda messaggio a A e setto count=0
sync(1) count = 0 aspetta messaggio da T
print(A)
sync(1) count = 1 manda messaggio a L e aspetto un messaggio da I
sync(3) count=0 aspetta messaggio da A
print(L)
sync(3) count = 1 manda messaggio a I e setto count=0
print(I) #si sblocca per il messaggio da L
sync(0) count=2 mando un messaggio ad A e mi blocco in attesa di un messaggio da A quando lo ricevo metto count=0
print(A)
sync(1) count=2 mando messaggio a I e aspetto messaggio da T e quando mi arriverà imposto count=0
</source>
Ma in realtà è tutto in parallelo quindi:
{| class="wikitable"
! Processo "I" !! Processo "A" !! Processo "T" !! Processo "L"
|-
|sync(0) non fa nulla print(I) sync(0) count=1 manda messaggio a T e si bloccherà in attesa di un messaggio da L print(I) #si sblocca per il messaggio da L sync(0) count=2 mando un messaggio ad A e mi blocco in attesa di un messaggio da A quando lo ricevo metto count=0
| sync(1) count = 0 aspetta messaggio da T print(A) sync(1) count = 1 manda messaggio a L e aspetto un messaggio da I print(A) sync(1) count=2 mando messaggio a I e aspetto messaggio da T e quando mi arriverà imposto count=0
|sync(2) count=0 aspetta messaggio da I print(T) sync(2) count = 1 manda messaggio a A e setto count=0
|sync(3) count=0 aspetta messaggio da A print(L) sync(3) count = 1 manda messaggio a I e setto count=0
|}

Prova teorica 2015.01.20

2017-06-14T06:51:17Z

FedericoB: /* Soluzione di FedericoB */ Eliminati controlli e contatori inutili.

Testo: [http://www.cs.unibo.it/~renzo/so/compiti/2015.01.20.tot.pdf]

== Esercizio c.1 ==
===Soluzione di S.G===
<syntaxhighlight lang="C">
/*
* Esercizio c.1: Scrivere il monitor lwlrbb. Il monitor deve implementare le seguenti procedure entry:
* void write(generic_type val);
* generic_type read(void);
* Il lwlrbb si comporta come un bounded buffer di MAX elementi che coordina l'attivita' di numerosi processi
* produttori/scrittori e numerosi lettori/consumatori. lwlrbb ammette un numero massimo (sempre MAX) di lettori
* e scrittori in attesa. Se il buffer e' vuoto e ci sono piu' gia' MAX lettori in attesa, il lettore che e' in
* attesa da piu' tempo esce resituendo NULL. In ugual modo se il buffer e' completamente pieno e ci sono gia' MAX
* scrittori che attendono di scrivere viene perduto il valore che da piu' tempo nel buffer attende di venir letto,
* il primo processo in attesa di scrivere puo' cosi' scrivere il suo elemento nel buffer e sbloccarsi.
*/
#define MAX

monitor lwlrbb{
generic_type bb[];
int count, rear, front, nw, nr;
bool exitNull;
conditions lw, lr;

void lwlrbb(void){
bb = new generic_type[MAX];
exitNull = FALSE;
rear = count = front = nw = nr = 0;
}

procedure entry void write(generic_type val){
if(count == MAX){ // Il buffer è completamente pieno
if(nw == MAX){ // ci sono già MAX scrittori che attendono di scrivere
rear = (rear + 1) % MAX; // Salto l'elemento da leggere da più tempo
count--;
lw.signal(); // il primo processo in attesa di scrivere puo' sbloccarsi.
}
nw++;
lw.wait();
nw--;
}
bb[front] = val; // Il buffer non è pieno, scrivo
count++;
front = (front + 1) % MAX;
lr.signal();
}

procedure entry generic_type read(void){
generic_type retval;
if(count == 0){ // Il buffer è vuoto
if(nr == MAX){ // ci sono gia MAX lettori in attesa
exitNull = TRUE; // quindi riattivio il lettore che e' in attesa da piu' tempo, restituendo NULL
lr.signal();
}
nr++; // incremento il contatore dei lettori in coda
lr.wait(); // metto in attesa il lettore
// Riprendo l'esecuzione da dove era stata interrotta
nr--; // decremento il contatore dei lettori in coda
if(exitNull){ // Controllo se è una richiesta di uscita forzata
exitNull = FALSE;
return NULL;
}
}
count--; // Il buffer non è vuoto, leggo
retval = bb[rear];
rear = (rear + 1) % MAX;
lw.signal();
}

}
</syntaxhighlight>

[[User:S.G|S.G]] ([[User talk:S.G|talk]]) 14:39, 18 November 2016 (CET) 
Ho scritto una possibile soluzione dell'esercizio c.1. Iniziare qui una discussione

'''è uno stack! bounded buffer deve implementare una coda.''' [[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 19:29, 21 November 2016 (CET)

Ho implementato la coda. [[User:S.G|S.G]] ([[User talk:S.G|talk]]) 10:12, 22 November 2016 (CET)
----
===Soluzione di BAGG===
<source lang="c">
#define MAX 42

monitor lwlrbb {
generic_type bb[] ;
int count, front, rear ; /* rispettivamente: numero elementi, dove scrivere nel buffer, dove leggere nel buffer */
int nw, nr ; /* rispettivamente numero di writer e reader */
bool exit ; /* server ai reader per sapere se devono ritornare NULL al loro rientro nel monitor */
condition canr, canw ;

lwlrbb(void) {
bb = new generic_type[MAX] ;
count = front = rear = nw = nr = exit = 0 ;
}

entry void write(generic_type val) {
if(count == MAX) { /* se count è MAX non si può scrivere */
if(nw == MAX) { /* se la coda è piena devo fare spazio */
rear = (rear + 1)%MAX ; /* rear indica il più vecchio elemento ancora da leggere, lo incremento --> salto l'elemento */
count -= 1 ;
nw += 1 ; /* incremento prima perchè anche se la coda è piena ora dopo la signal ci sarà un posto... */
canw.signal() ; /* ora il primo che aspettava può scrivere --> lo sveglio */
canw.wait() ;
nw -= 1 ;
} else { /* se la coda non è piena devo comunque aspettare... */
nw += 1 ;
canw.wait() ;
nw -=1 ;
}
}
bb[front] = val ;
front = (front + 1)%MAX ;
count += 1 ;
canr.signal() ; /* potrebbe esserci un reader che aspetta --> segnalo che ho scritto e si può leggere */
}

entry generic_type read(void) {
if(count == 0) { /* se non c'è nulla da leggere allora devo aspettare */
if(nr == MAX) { /* se la coda è piena setto exit, che i reader controllano per sapere se sono stati svegliati per ritornare NULL */
exit = 1 ;
canr.signal() ; /* sveglio il condannato... */
} nr += 1 ; /* mi accodo... */
canr.wait() ;
nr -= 1 ;
if(exit) { /* se sono il condannato resetto la variabile ed esco... */
exit = 0 ;
return NULL ;
}
}
generic_type r = bb[rear] ;
rear = (rear + 1)%MAX ;
count -= 1 ;
canw.signal() ; /* ho letto, quindi si è liberato un posto e almeno un writer può scrivere... */
return r ;
}
}
</source>
===Soluzione di FedericoB===
Essendo l'accesso al monitor in mutua esclusione non c'è da considerare il caso in cui ci siano più lettori in concorrenza. 
La mia soluzione cerca di essere equa alternando scrittori a lettori.
<source lang="Python">
monitor lwlrbb:

Queue[generic_type] buffer
int waitingReaders, waitingWriters
condition ok2write, ok2read
boolean exitNull;
int max;

lwlrbb (int max):
self.max = max
buffer = new List(max)
waitingReaders = 0
waitingWriters = 0
exitNull = False

@entry
void write(generic_type val):
if (buffer.size()>=MAX) :
if (waitingWriters>Max):
buffer.dequeue() #discard element
ok2write.signal()
waitingWriters+=1
ok2write.wait()
waitingWriters-=1
buffer.enqueue(val)
if (waitingReaders>0) ok2read.signal()
else if (waitingWriters>0) ok2write.signal()

@entry
generic_type read():
if (buffer.isEmpty():
if (waitingReaders>Max):
exitNull = True #set flag to make the woke up reader return null
ok2read.signal()
waitingReaders++
ok2read.wait()
waitingReaders--
if (exitNull):
exitNull = False
return null
element = buffer.dequeue()
if (waitingWriters>0) ok2write.signal()
else if (waitingReaders>0) ok2read.signal()

</source>

===Soluzione di sav, correggetemi se sbaglio ===
<source lang="Python">
monitor lwlbb
{
buffer buf, wr //buf = buffer di elementi e wr buffer di lettori
condition oktoread, oktowrite

Procedure entry read {

if ( wr.len() < MAXLETTORI)
if (buf.len() == 0)
wr. enqueue(lettore)
oktoread.wait(lettore)
wr.dequeue(lettore)
buf.dequeue()
oktoread.signal()
wr.dequeue()
wr.enqueue(lettore)

}

procedure entry write (val) { //lo scrittore non resterà mai in attesa perché se non c'è spazio nel buffer toglie
//il primo elemento inserito e mette il suo nuovo e sblocca un eventuale lettore in attesa

if (buf.len()< MAXBUFFER)
buf.enqueue(val)
oktoread.signal()
buf.dequeue()
buf.enqueue(val)
oktoread.signal()
}
}

</source>

== Esercizio c.2 ==
===Soluzione di S.G===
a) Si consideri la funzione atomica dualshift(a,b) che opera su due operandi di tipo byte passati per indirizzo. L'operazione fa lo shift a
destra dei due operandi. Il bit piu' significativo di a viene posto a zero, il bit piu' significativo di b diviene quello che all'atto della
attivazione di dualshift era il bit meno significativo di a.
es. se a vale 6 e b vale 4 dopo la chiamata di dualshift(a,b) a vale 3 e b 2. Se a vale 5 e b 6 dopo la chiamata dualshift (a,b) a vale 2
e b vale 131 (128+3).
La funzione dualshift puo' essere usata al posto della test&set per la sincronizzazione fra processi? Dimostrare la risposta.
b) Si consideri ora la funzione andor(a,b) che opera su due opera su due parametri di tipo booleano passati per indirizzo e cosi'
definita:
andor(a,b)=<c=a or b; b=a and b; a=c>
Puo' la funzione andor essere usata al posto della test&set per la sincronizzazione fra processi? Dimostrare la risposta.
Si ricorda che le operazioni di assegnazione di valori costanti a variabili vengono considerati atomici.

Svolgimento

a) Non è possibile utilizzare la funzione atomica dualshift(a,b) in quanto per la definizione di test&set(a,b)
<syntaxhighlight lang="C">
test&set(a,b){
a = b;
b = X; // Dove X è un valore costante
}
</syntaxhighlight>
La funzione dualshift dovrebbe memorizzare (in qualche modo) il valore precedente di a (o b), e successivamente settare a (o b) ad un valore costante. Questo non accade perchè la stessa funzione divide per 2 i valori di a e b ogni volta che viene richiamata (caso particolare in cui venga copiato il bit meno significativo di a nel bit più significativo di b). Quindi è impossibile soddisfare la richiesta.

b) La funzione andor(a,b) può essere utilizzata al posto della test&set per la sincronizzazione fra processi.
Dimostrazione.
La funzione andor(a,b) è definita come segue:

<syntaxhighlight lang="C">
andor(a, b){
c = a | b;
b = b & a;
a = c;
}
</syntaxhighlight>
Posto a = 0, non avremo altro che:

<syntaxhighlight lang="C">
andor(a, b){
c = b;
b = 0;
a = c;
}
</syntaxhighlight>

Quindi la funzione andor, non è altro che una semplice test&set.

<syntaxhighlight lang="C">
a = 0;
b = 1;

Process P {
do{
andor(a, b);
} while(!a);
//critical section
b = 1;
// non-critical section
}
</syntaxhighlight>
[[User:S.G|S.G]] ([[User talk:S.G|talk]]) 14:39, 18 November 2016 (CET) 
Ho scritto una possibile soluzione dell'esercizio c.2. Iniziare qui una discussione

'''a è errato, pensateci meglio. Per B la variabile a va indicata come locale al processo P (generico) che deve avere un loop infinito.''' [[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 19:25, 21 November 2016 (CET)

Quindi una soluzione del genere potrebbe andar bene? [[User:S.G|S.G]] ([[User talk:S.G|talk]]) 09:23, 22 November 2016 (CET)
<syntaxhighlight lang="C">
b = 0;

Process P {
do{
a = 1;
dualshift(a, b);
} while(b != 128);
//critical section
b = 0;
// non-critical section
}
</syntaxhighlight>
----
===Soluzione di FedericoB===
<source lang="text">
dualshift(a,b) |xxxxxxxx|yyyyyyyy| -> |0xxxxxxx|xyyyyyyy|
G=1
MUTEXIN
do:
L=0
dualshift(G,L)
while L==0;
MUTEXOUT
G=1
</source>

== Esercizio g.1 ==

a) Sia data la seguente stringa di riferimenti: 123451234123121.
mostrare il comportamento degli algoritmi MIN e LRU quando operano su una memoria di 3 frame.
b) Data una memoria di 4 frame contenente la pagina 4 nel frame 1, la pagina 3 nel frame 2, la pagina 2 nel frame 3 e infine la
pagina 1 nel frame 4. Mostrare una stringa di riferimenti di un programma che usi 5 pagine (esiste la pagina 5 non ancora mappata in
memoria oltre alle 4 cariate nei frame) e che consenta alla fine dell'esecuzione di avere tutte le pagine nel frame di indice
corrispondente. La pagina 1 nel frame 1, la pagina 2 nel frame 2 e cosi' via.

Esecuzione algoritmo MIN
<syntaxhighlight lang="C">
-------------------------------------------------------------
| 1 | 2 | 3 | 4 | 5 | 1 | 2 | 3 | 4 | 1 | 2 | 3 | 1 | 2 | 1 |
-------------------------------------------------------------

-------------------------------------------------------------
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
-------------------------------------------------------------
| | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
-------------------------------------------------------------
| | | 3 | 4 | 5 | 5 | 5 | 3 | 4 | 4 | 4 | 3 | 3 | 3 | 3 |
-------------------------------------------------------------
</syntaxhighlight>

Esecuzione algoritmo LRU
<syntaxhighlight lang="C">
-------------------------------------------------------------
| 1 | 2 | 3 | 4 | 5 | 1 | 2 | 3 | 4 | 1 | 2 | 3 | 1 | 2 | 1 |
-------------------------------------------------------------

-------------------------------------------------------------
| 1 | 1 | 1 | 4 | 4 | 4 | 2 | 2 | 2 | 1 | 1 | 1 | 1 | 1 | 1 |
-------------------------------------------------------------
| | 2 | 2 | 2 | 5 | 5 | 5 | 3 | 3 | 3 | 2 | 2 | 2 | 2 | 2 |
-------------------------------------------------------------
| | | 3 | 3 | 3 | 1 | 1 | 1 | 4 | 4 | 4 | 3 | 3 | 3 | 3 |
-------------------------------------------------------------
</syntaxhighlight>

Una possibile sequenza utilizzando l'algoritmo con sostituzione FIFO
<syntaxhighlight lang="C">
-------------------------------------------------------------
| 4 | 3 | 2 | 1 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 |
-------------------------------------------------------------
</syntaxhighlight>
[[User:S.G|S.G]] ([[User talk:S.G|talk]]) 12:19, 19 November 2016 (CET) 
Ho scritto una possibile soluzione dell'esercizio g.1. Iniziare qui una discussione

'''Cosa significa proporre a novembre le risposte a quesiti relativi a argomenti che spieghero' a marzo 2017?'''[[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 19:20, 21 November 2016 (CET)

Mi scuso per l'inconveniente, avendo seguito il corso di SO 2015/2016 ho pensato di creare una sezione PROVE SVOLTE che fosse ben visibile a tutti i corsi sia per gli anni precedenti sia per gli anni successi
[[User:S.G|S.G]] ([[User talk:S.G|talk]]) 09:17, 22 November 2016 (CET)
----

== Esercizio g.2 ==

a) Se un sistema ha una RAM molto ampia puo' non essere utile usare la memoria virtuale. In questo caso ha senso egualmente
usare la paginazione di memoria? Perche'?

b) Perche' i metodi di sincronizzazione tipo test&set (detti anche spinlock) assumono grande rilevanza nella scrittura di sistemi
operativi multiprocessore?

c) Confrontare gli alogritmi di scheduling roud robin e a priorita' statica. Indicare in quali casi sono da usare algoritmi di tipo round
robin e quando quelli a priorita' statica.

Svolgimento

a) Paginazione è un metodo di gestione della memoria che permette che lo spazio degli indirizzi fisici di un processo
non sia contiguo, inoltre ha i seguenti vantaggi:
- riduce il fenomeno della frammentazione interna
- minimizza (elimina) il fenomeno della frammentazione esterna

b) Perchè permette di risolve il problema della sezione critica in modo relativamente semplice. Infatti l'istruzione
test&set è eseguita atomicamente, cioè come un'unita non soggetta a interruzzioni; quindi se si eseguono contemporaneamente
due istruzioni test&set, ciascuna su processori diversi, queste vengono eseguite in modo sequenziale in un ordine arbitrario.

c) Scheduling a priorità statica associa una priorità a ogni processo e si assegna la CPU
al processo con priorità più alta; i processi con priorità uguali si ordinano secondo una politica
FCFS. Questo algoritmo può essere sia con prelazione sia senza prelazione, inoltre soffre dell'attesa
indefinita (starvation). Infatti un flusso costante di processi con priorità maggiore può impedire a
un processo con priorità più bassa di accedere alla CPU. E' possibile utilizzare questo algoritmo quando
alcuni processi hanno più importanza di altri. es: nel caso di sistemi multimediali, come una smart TV, il
processo di riproduzione video è più importante rispetto ad un processo gestore di posta, altrimenti il flusso video
potrebbe essere discontinuo.

Scheduling circolare (round-robin) è un algoritmo con prelazione in cui ogni processo viene eseguito al massimo
per un quanto di tempo. E' bene che il quanto di tempo sia maggiore del tempo necessario al cambio di contesto.
Questo algoritmo a differenza dello scheduling a priorità statica non soffre di starvation. E' possibile utilizzare
questo algoritmo in sistemi in cui si pretende un finto parallelismo. es: nel caso in cui più studenti accedano ad
una determinata macchina del laboratorio.

[[User:S.G|S.G]] ([[User talk:S.G|talk]]) 11:24, 21 November 2016 (CET)

'''Cosa significa proporre a novembre le risposte a quesiti relativi a argomenti che spieghero' nel secondo semestre?'''[[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 19:21, 21 November 2016 (CET)

Mi scuso per l'inconveniente, avendo seguito il corso di SO 2015/2016 ho pensato di creare una sezione PROVE SVOLTE che fosse ben visibile a tutti i corsi sia per gli anni precedenti sia per gli anni successi. [[User:S.G|S.G]] ([[User talk:S.G|talk]]) 09:19, 22 November 2016 (CET)

Prova teorica 2015.01.20

2017-06-13T20:25:56Z

FedericoB: /* Soluzione di FedericoB */ Corretta soluzione precendente che era sbagliata, quella attuale si può migliorare.

Testo: [http://www.cs.unibo.it/~renzo/so/compiti/2015.01.20.tot.pdf]

== Esercizio c.1 ==
===Soluzione di S.G===
<syntaxhighlight lang="C">
/*
* Esercizio c.1: Scrivere il monitor lwlrbb. Il monitor deve implementare le seguenti procedure entry:
* void write(generic_type val);
* generic_type read(void);
* Il lwlrbb si comporta come un bounded buffer di MAX elementi che coordina l'attivita' di numerosi processi
* produttori/scrittori e numerosi lettori/consumatori. lwlrbb ammette un numero massimo (sempre MAX) di lettori
* e scrittori in attesa. Se il buffer e' vuoto e ci sono piu' gia' MAX lettori in attesa, il lettore che e' in
* attesa da piu' tempo esce resituendo NULL. In ugual modo se il buffer e' completamente pieno e ci sono gia' MAX
* scrittori che attendono di scrivere viene perduto il valore che da piu' tempo nel buffer attende di venir letto,
* il primo processo in attesa di scrivere puo' cosi' scrivere il suo elemento nel buffer e sbloccarsi.
*/
#define MAX

monitor lwlrbb{
generic_type bb[];
int count, rear, front, nw, nr;
bool exitNull;
conditions lw, lr;

void lwlrbb(void){
bb = new generic_type[MAX];
exitNull = FALSE;
rear = count = front = nw = nr = 0;
}

procedure entry void write(generic_type val){
if(count == MAX){ // Il buffer è completamente pieno
if(nw == MAX){ // ci sono già MAX scrittori che attendono di scrivere
rear = (rear + 1) % MAX; // Salto l'elemento da leggere da più tempo
count--;
lw.signal(); // il primo processo in attesa di scrivere puo' sbloccarsi.
}
nw++;
lw.wait();
nw--;
}
bb[front] = val; // Il buffer non è pieno, scrivo
count++;
front = (front + 1) % MAX;
lr.signal();
}

procedure entry generic_type read(void){
generic_type retval;
if(count == 0){ // Il buffer è vuoto
if(nr == MAX){ // ci sono gia MAX lettori in attesa
exitNull = TRUE; // quindi riattivio il lettore che e' in attesa da piu' tempo, restituendo NULL
lr.signal();
}
nr++; // incremento il contatore dei lettori in coda
lr.wait(); // metto in attesa il lettore
// Riprendo l'esecuzione da dove era stata interrotta
nr--; // decremento il contatore dei lettori in coda
if(exitNull){ // Controllo se è una richiesta di uscita forzata
exitNull = FALSE;
return NULL;
}
}
count--; // Il buffer non è vuoto, leggo
retval = bb[rear];
rear = (rear + 1) % MAX;
lw.signal();
}

}
</syntaxhighlight>

[[User:S.G|S.G]] ([[User talk:S.G|talk]]) 14:39, 18 November 2016 (CET) 
Ho scritto una possibile soluzione dell'esercizio c.1. Iniziare qui una discussione

'''è uno stack! bounded buffer deve implementare una coda.''' [[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 19:29, 21 November 2016 (CET)

Ho implementato la coda. [[User:S.G|S.G]] ([[User talk:S.G|talk]]) 10:12, 22 November 2016 (CET)
----
===Soluzione di BAGG===
<source lang="c">
#define MAX 42

monitor lwlrbb {
generic_type bb[] ;
int count, front, rear ; /* rispettivamente: numero elementi, dove scrivere nel buffer, dove leggere nel buffer */
int nw, nr ; /* rispettivamente numero di writer e reader */
bool exit ; /* server ai reader per sapere se devono ritornare NULL al loro rientro nel monitor */
condition canr, canw ;

lwlrbb(void) {
bb = new generic_type[MAX] ;
count = front = rear = nw = nr = exit = 0 ;
}

entry void write(generic_type val) {
if(count == MAX) { /* se count è MAX non si può scrivere */
if(nw == MAX) { /* se la coda è piena devo fare spazio */
rear = (rear + 1)%MAX ; /* rear indica il più vecchio elemento ancora da leggere, lo incremento --> salto l'elemento */
count -= 1 ;
nw += 1 ; /* incremento prima perchè anche se la coda è piena ora dopo la signal ci sarà un posto... */
canw.signal() ; /* ora il primo che aspettava può scrivere --> lo sveglio */
canw.wait() ;
nw -= 1 ;
} else { /* se la coda non è piena devo comunque aspettare... */
nw += 1 ;
canw.wait() ;
nw -=1 ;
}
}
bb[front] = val ;
front = (front + 1)%MAX ;
count += 1 ;
canr.signal() ; /* potrebbe esserci un reader che aspetta --> segnalo che ho scritto e si può leggere */
}

entry generic_type read(void) {
if(count == 0) { /* se non c'è nulla da leggere allora devo aspettare */
if(nr == MAX) { /* se la coda è piena setto exit, che i reader controllano per sapere se sono stati svegliati per ritornare NULL */
exit = 1 ;
canr.signal() ; /* sveglio il condannato... */
} nr += 1 ; /* mi accodo... */
canr.wait() ;
nr -= 1 ;
if(exit) { /* se sono il condannato resetto la variabile ed esco... */
exit = 0 ;
return NULL ;
}
}
generic_type r = bb[rear] ;
rear = (rear + 1)%MAX ;
count -= 1 ;
canw.signal() ; /* ho letto, quindi si è liberato un posto e almeno un writer può scrivere... */
return r ;
}
}
</source>
===Soluzione di FedericoB===
Pseudocodice simil python. Forse soluzione troppo lunga, si può migliorare.
<source lang="Python">
monitor lwlrbb

Queue[generic_type] buffer
int numWriter, numReader, waitingReader, waitingWriters
condition ok2write, ok2read
int max;

lwlrbb (int max)
self.max = max
buffer = new List(max)
numWriter = 0
numReader = 0
waitingReader = 0
write_last = false;

@entry
void write(generic_type val)
if (buffer.size()>=MAX) and (waitingWriters>Max)
#wakeup for discard
ok2write.signal()
if (numWriter>0 or numReader>0) or (buffer.size>=MAX)
waitingWriters+=1
ok2write.wait()
waitingWriters-=1
if (waitingReader >=Max)
buffer.dequeue()
ok2write.signal()
return;
numWriter+=1
buffer.enqueue(val)
numWriter-=1
ok2write.signal()
if (waitingReader>0) ok2read.signal()
else if (waitingWriters>0) ok2write.signal()

@entry
generic_type read()
if (buffer.isEmpty()
if (waitingReader>Max):
#do not decrement waitingReader
ok2read.signal()
else
waitingReader+=1
ok2read.wait()
if (nwriter>0 or waitingWriters>0)
waitingReader +=1
ok2read.wait()
waitingReader-=1
if (waitingReader >= max)
ok2read.signal()
return null
else
numReader+=1
element = buffer.dequeue()
numReader-=1
if (waitingReader>0) ok2read.signal()
else if (waitingWriters>0) ok2write.signal()

</source>

===Soluzione di sav, correggetemi se sbaglio ===
<source lang="Python">
monitor lwlbb
{
buffer buf, wr //buf = buffer di elementi e wr buffer di lettori
condition oktoread, oktowrite

Procedure entry read {

if ( wr.len() < MAXLETTORI)
if (buf.len() == 0)
wr. enqueue(lettore)
oktoread.wait(lettore)
wr.dequeue(lettore)
buf.dequeue()
oktoread.signal()
wr.dequeue()
wr.enqueue(lettore)

}

procedure entry write (val) { //lo scrittore non resterà mai in attesa perché se non c'è spazio nel buffer toglie
//il primo elemento inserito e mette il suo nuovo e sblocca un eventuale lettore in attesa

if (buf.len()< MAXBUFFER)
buf.enqueue(val)
oktoread.signal()
buf.dequeue()
buf.enqueue(val)
oktoread.signal()
}
}

</source>

== Esercizio c.2 ==
===Soluzione di S.G===
a) Si consideri la funzione atomica dualshift(a,b) che opera su due operandi di tipo byte passati per indirizzo. L'operazione fa lo shift a
destra dei due operandi. Il bit piu' significativo di a viene posto a zero, il bit piu' significativo di b diviene quello che all'atto della
attivazione di dualshift era il bit meno significativo di a.
es. se a vale 6 e b vale 4 dopo la chiamata di dualshift(a,b) a vale 3 e b 2. Se a vale 5 e b 6 dopo la chiamata dualshift (a,b) a vale 2
e b vale 131 (128+3).
La funzione dualshift puo' essere usata al posto della test&set per la sincronizzazione fra processi? Dimostrare la risposta.
b) Si consideri ora la funzione andor(a,b) che opera su due opera su due parametri di tipo booleano passati per indirizzo e cosi'
definita:
andor(a,b)=<c=a or b; b=a and b; a=c>
Puo' la funzione andor essere usata al posto della test&set per la sincronizzazione fra processi? Dimostrare la risposta.
Si ricorda che le operazioni di assegnazione di valori costanti a variabili vengono considerati atomici.

Svolgimento

a) Non è possibile utilizzare la funzione atomica dualshift(a,b) in quanto per la definizione di test&set(a,b)
<syntaxhighlight lang="C">
test&set(a,b){
a = b;
b = X; // Dove X è un valore costante
}
</syntaxhighlight>
La funzione dualshift dovrebbe memorizzare (in qualche modo) il valore precedente di a (o b), e successivamente settare a (o b) ad un valore costante. Questo non accade perchè la stessa funzione divide per 2 i valori di a e b ogni volta che viene richiamata (caso particolare in cui venga copiato il bit meno significativo di a nel bit più significativo di b). Quindi è impossibile soddisfare la richiesta.

b) La funzione andor(a,b) può essere utilizzata al posto della test&set per la sincronizzazione fra processi.
Dimostrazione.
La funzione andor(a,b) è definita come segue:

<syntaxhighlight lang="C">
andor(a, b){
c = a | b;
b = b & a;
a = c;
}
</syntaxhighlight>
Posto a = 0, non avremo altro che:

<syntaxhighlight lang="C">
andor(a, b){
c = b;
b = 0;
a = c;
}
</syntaxhighlight>

Quindi la funzione andor, non è altro che una semplice test&set.

<syntaxhighlight lang="C">
a = 0;
b = 1;

Process P {
do{
andor(a, b);
} while(!a);
//critical section
b = 1;
// non-critical section
}
</syntaxhighlight>
[[User:S.G|S.G]] ([[User talk:S.G|talk]]) 14:39, 18 November 2016 (CET) 
Ho scritto una possibile soluzione dell'esercizio c.2. Iniziare qui una discussione

'''a è errato, pensateci meglio. Per B la variabile a va indicata come locale al processo P (generico) che deve avere un loop infinito.''' [[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 19:25, 21 November 2016 (CET)

Quindi una soluzione del genere potrebbe andar bene? [[User:S.G|S.G]] ([[User talk:S.G|talk]]) 09:23, 22 November 2016 (CET)
<syntaxhighlight lang="C">
b = 0;

Process P {
do{
a = 1;
dualshift(a, b);
} while(b != 128);
//critical section
b = 0;
// non-critical section
}
</syntaxhighlight>
----
===Soluzione di FedericoB===
<source lang="text">
dualshift(a,b) |xxxxxxxx|yyyyyyyy| -> |0xxxxxxx|xyyyyyyy|
G=1
MUTEXIN
do:
L=0
dualshift(G,L)
while L==0;
MUTEXOUT
G=1
</source>

== Esercizio g.1 ==

a) Sia data la seguente stringa di riferimenti: 123451234123121.
mostrare il comportamento degli algoritmi MIN e LRU quando operano su una memoria di 3 frame.
b) Data una memoria di 4 frame contenente la pagina 4 nel frame 1, la pagina 3 nel frame 2, la pagina 2 nel frame 3 e infine la
pagina 1 nel frame 4. Mostrare una stringa di riferimenti di un programma che usi 5 pagine (esiste la pagina 5 non ancora mappata in
memoria oltre alle 4 cariate nei frame) e che consenta alla fine dell'esecuzione di avere tutte le pagine nel frame di indice
corrispondente. La pagina 1 nel frame 1, la pagina 2 nel frame 2 e cosi' via.

Esecuzione algoritmo MIN
<syntaxhighlight lang="C">
-------------------------------------------------------------
| 1 | 2 | 3 | 4 | 5 | 1 | 2 | 3 | 4 | 1 | 2 | 3 | 1 | 2 | 1 |
-------------------------------------------------------------

-------------------------------------------------------------
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
-------------------------------------------------------------
| | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 | 2 |
-------------------------------------------------------------
| | | 3 | 4 | 5 | 5 | 5 | 3 | 4 | 4 | 4 | 3 | 3 | 3 | 3 |
-------------------------------------------------------------
</syntaxhighlight>

Esecuzione algoritmo LRU
<syntaxhighlight lang="C">
-------------------------------------------------------------
| 1 | 2 | 3 | 4 | 5 | 1 | 2 | 3 | 4 | 1 | 2 | 3 | 1 | 2 | 1 |
-------------------------------------------------------------

-------------------------------------------------------------
| 1 | 1 | 1 | 4 | 4 | 4 | 2 | 2 | 2 | 1 | 1 | 1 | 1 | 1 | 1 |
-------------------------------------------------------------
| | 2 | 2 | 2 | 5 | 5 | 5 | 3 | 3 | 3 | 2 | 2 | 2 | 2 | 2 |
-------------------------------------------------------------
| | | 3 | 3 | 3 | 1 | 1 | 1 | 4 | 4 | 4 | 3 | 3 | 3 | 3 |
-------------------------------------------------------------
</syntaxhighlight>

Una possibile sequenza utilizzando l'algoritmo con sostituzione FIFO
<syntaxhighlight lang="C">
-------------------------------------------------------------
| 4 | 3 | 2 | 1 | 5 | 6 | 7 | 8 | 9 | 0 | 1 | 2 | 3 | 4 | 5 |
-------------------------------------------------------------
</syntaxhighlight>
[[User:S.G|S.G]] ([[User talk:S.G|talk]]) 12:19, 19 November 2016 (CET) 
Ho scritto una possibile soluzione dell'esercizio g.1. Iniziare qui una discussione

'''Cosa significa proporre a novembre le risposte a quesiti relativi a argomenti che spieghero' a marzo 2017?'''[[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 19:20, 21 November 2016 (CET)

Mi scuso per l'inconveniente, avendo seguito il corso di SO 2015/2016 ho pensato di creare una sezione PROVE SVOLTE che fosse ben visibile a tutti i corsi sia per gli anni precedenti sia per gli anni successi
[[User:S.G|S.G]] ([[User talk:S.G|talk]]) 09:17, 22 November 2016 (CET)
----

== Esercizio g.2 ==

a) Se un sistema ha una RAM molto ampia puo' non essere utile usare la memoria virtuale. In questo caso ha senso egualmente
usare la paginazione di memoria? Perche'?

b) Perche' i metodi di sincronizzazione tipo test&set (detti anche spinlock) assumono grande rilevanza nella scrittura di sistemi
operativi multiprocessore?

c) Confrontare gli alogritmi di scheduling roud robin e a priorita' statica. Indicare in quali casi sono da usare algoritmi di tipo round
robin e quando quelli a priorita' statica.

Svolgimento

a) Paginazione è un metodo di gestione della memoria che permette che lo spazio degli indirizzi fisici di un processo
non sia contiguo, inoltre ha i seguenti vantaggi:
- riduce il fenomeno della frammentazione interna
- minimizza (elimina) il fenomeno della frammentazione esterna

b) Perchè permette di risolve il problema della sezione critica in modo relativamente semplice. Infatti l'istruzione
test&set è eseguita atomicamente, cioè come un'unita non soggetta a interruzzioni; quindi se si eseguono contemporaneamente
due istruzioni test&set, ciascuna su processori diversi, queste vengono eseguite in modo sequenziale in un ordine arbitrario.

c) Scheduling a priorità statica associa una priorità a ogni processo e si assegna la CPU
al processo con priorità più alta; i processi con priorità uguali si ordinano secondo una politica
FCFS. Questo algoritmo può essere sia con prelazione sia senza prelazione, inoltre soffre dell'attesa
indefinita (starvation). Infatti un flusso costante di processi con priorità maggiore può impedire a
un processo con priorità più bassa di accedere alla CPU. E' possibile utilizzare questo algoritmo quando
alcuni processi hanno più importanza di altri. es: nel caso di sistemi multimediali, come una smart TV, il
processo di riproduzione video è più importante rispetto ad un processo gestore di posta, altrimenti il flusso video
potrebbe essere discontinuo.

Scheduling circolare (round-robin) è un algoritmo con prelazione in cui ogni processo viene eseguito al massimo
per un quanto di tempo. E' bene che il quanto di tempo sia maggiore del tempo necessario al cambio di contesto.
Questo algoritmo a differenza dello scheduling a priorità statica non soffre di starvation. E' possibile utilizzare
questo algoritmo in sistemi in cui si pretende un finto parallelismo. es: nel caso in cui più studenti accedano ad
una determinata macchina del laboratorio.

[[User:S.G|S.G]] ([[User talk:S.G|talk]]) 11:24, 21 November 2016 (CET)

'''Cosa significa proporre a novembre le risposte a quesiti relativi a argomenti che spieghero' nel secondo semestre?'''[[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 19:21, 21 November 2016 (CET)

Mi scuso per l'inconveniente, avendo seguito il corso di SO 2015/2016 ho pensato di creare una sezione PROVE SVOLTE che fosse ben visibile a tutti i corsi sia per gli anni precedenti sia per gli anni successi. [[User:S.G|S.G]] ([[User talk:S.G|talk]]) 09:19, 22 November 2016 (CET)

Prova teorica 2015.02.14

2017-06-13T18:58:57Z

FedericoB: /* Soluzione di Silas */ Migliorata formattazione e aggiunta peer review.

Testo: [http://www.cs.unibo.it/~renzo/so/compiti/2015.02.14.tot.pdf]

== Esercizio c.1 ==
===Soluzione di Silas===
<syntaxhighlight lang="C">
#define MAX

monitor altcolbb{
queue buff;
color_t last_color; //0: red, 1:blue, -1:"superstate", means that both red and blue are accepted
int wait_red, wait_blue;
condition ok2read, redok, blueok;

void altcolbb(void){
buff = new queue();
last_color = -1;
wait_red = wait_blue = 0;
}

procedure entry void write(color_t color, generic_type val){
if(last_color == color || buff.length() == MAX){ //we can't enqueue if the colors are the same or if the buffer is full
if(color == 0){ //enqueue to "reds"
wait_red++;
redok.wait();
wait_red--;
}else{ //enqueue to "blues"
wait_blue++;
blueok.wait();
wait_blue--;
}
}
buff.enqueue(val); //append val and update last_color
last_color = color;
ok2read.signal();
}

procedure entry generic_type read(void){
if(buff.length() == 0)
ok2read.wait();
generic_type ret = buff.dequeue();
if(buff.length() == 0)
last_color = -1; //if buff is empty both colors can now be added
switch(last_color){
case -1: {
if(wait_red>wait_blue) //if there are more "reds" waiting to write we signal them
redok.signal();
else
blueok.signal(); //otherwise we signal "blues"
break;
}
case 0: {
blueok.signal();
break;
}
case 1: {
redok.signal();
break;
}
}
}

}
</syntaxhighlight>

===Soluzione di MarcoNegrini===
I corrected Silas's version
<syntaxhighlight lang="C">

#define MAX

monitor altcolbb{
queue buff;
color_t last_color; //0: red, 1:blue, -1:"superstate", means that both red and blue are accepted
condition ok2read, ok2write, redok, blueok;

void altcolbb(void){
buff = new queue();
last_color = -1;
}

procedure entry void write(color_t color, generic_type val){
if(buff.length() == MAX){ //here waits if buff is full
ok2write.wait();
if(last_color==-1){ //if buff was empty it can just enqueue and exit
buff.enqueue(val);
last_color = color;
}
else{
if(color == 0){ //red section
if (last_color == 0) //if last was red it needs to wait
redok.wait();
buff.enqueue(val);
last_color = color; // it must set last color before signaling other writers
blueok.signal(); //blue can now enqueue his value
}else{ //blue section, same as above
if (last_color == 1)
blueok.wait();
buff.enqueue(val);
last_color = color;
redok.signal();
}
}
ok2read.signal(); // reader can now read
}

procedure entry generic_type read(void){
//here waits if needed, then dequeue
if(buff.length() == 0)
ok2read.wait();
generic_type ret = buff.dequeue();

//here signal the one that has been waiting for more time
// it MUST be of the last_color color
if(buff.length() == 0){
color_t tmp=last_color;
last_color = -1;
// last color MUST be set to -1 here because
// if there were writers waiting on ok2write.wait() (full buffer case)
// they woundn't be signaled here, this happens if MAX=1

if (tmp == 1) //
blueok.signal();
else
redok.signal();
}
ok2write.signal();
}

}
</syntaxhighlight>
===Soluzione di FedericoB===
relating to Silas and Marco solution. A bounded buffer is a queue, so i think is wrong to use last_color as head element color when it's used as tail element color.
<source lang="python">
#define MAX

monitor altcobb {
deque buffer
condition waitRed, waitBlue, ok2read, ok2write
altcobb() {
buffer = new Deque()

}
procedure entry void write(colot_t color,generic_type val) {
if (deque.getSize()==MAX) ok2write.wait()
if (buffer.getSize==0) queue.addLast((val,color))
else
if (color==RED)
if (buffer.getLast().color==BLUE)
queue.addLast((val,color))
waitRed.signal()
else
waitBlue.wait()
queue.addLast((val,color))
else
if (buffer.getLast().color==RED)
queue.addLast((val,color))
waitBlue.signal()
else
waitRed.wait()
queue.addLast((val,color))
ok2read.signal()
}
procedure entry generic_type read() {
if (deque.isEmpty()) ok2read.wait()
element = deque.dequeueFirst();
ok2write.signal()
return element;
#needed explanation: after the ok2write.signal() the current process will be put in wait state in the urgent stack,
#but after the woke up process has exited the monitor this process will be woke up and it will return the element.
}
}
</source>

== Esercizio c.2 ==
===Soluzione di Silas===
I semafori garantiscono che A e B vengano eseguiti in maniera sequenziale e che accedano in maniera mutualmente esclusiva ad n, quindi l'unica variazione possibile è il thread di inizio per la sequenza. 
Nel caso sia A ad accedere per primo alla CS si ha: n = ((1*2)+2)*3 = 12 
Nel caso sia invece B ad accedere per primo alla C si ha: n = (((0*2)+1)*3)+2 = 5 
Quindi n = 12 e n = 5 sono i due possibili valori. 

Anche secondo me è così --[[User:FedericoB|FedericoB]] ([[User talk:FedericoB|talk]]) 20:58, 13 June 2017 (CEST)

Prova teorica 2015.02.14

2017-06-13T16:33:04Z

FedericoB: /* Esercizio c.1 */ Aggiunta soluzione

Testo: [http://www.cs.unibo.it/~renzo/so/compiti/2015.02.14.tot.pdf]

== Esercizio c.1 ==
===Soluzione di Silas===
<syntaxhighlight lang="C">
#define MAX

monitor altcolbb{
queue buff;
color_t last_color; //0: red, 1:blue, -1:"superstate", means that both red and blue are accepted
int wait_red, wait_blue;
condition ok2read, redok, blueok;

void altcolbb(void){
buff = new queue();
last_color = -1;
wait_red = wait_blue = 0;
}

procedure entry void write(color_t color, generic_type val){
if(last_color == color || buff.length() == MAX){ //we can't enqueue if the colors are the same or if the buffer is full
if(color == 0){ //enqueue to "reds"
wait_red++;
redok.wait();
wait_red--;
}else{ //enqueue to "blues"
wait_blue++;
blueok.wait();
wait_blue--;
}
}
buff.enqueue(val); //append val and update last_color
last_color = color;
ok2read.signal();
}

procedure entry generic_type read(void){
if(buff.length() == 0)
ok2read.wait();
generic_type ret = buff.dequeue();
if(buff.length() == 0)
last_color = -1; //if buff is empty both colors can now be added
switch(last_color){
case -1: {
if(wait_red>wait_blue) //if there are more "reds" waiting to write we signal them
redok.signal();
else
blueok.signal(); //otherwise we signal "blues"
break;
}
case 0: {
blueok.signal();
break;
}
case 1: {
redok.signal();
break;
}
}
}

}
</syntaxhighlight>

===Soluzione di MarcoNegrini===
I corrected Silas's version
<syntaxhighlight lang="C">

#define MAX

monitor altcolbb{
queue buff;
color_t last_color; //0: red, 1:blue, -1:"superstate", means that both red and blue are accepted
condition ok2read, ok2write, redok, blueok;

void altcolbb(void){
buff = new queue();
last_color = -1;
}

procedure entry void write(color_t color, generic_type val){
if(buff.length() == MAX){ //here waits if buff is full
ok2write.wait();
if(last_color==-1){ //if buff was empty it can just enqueue and exit
buff.enqueue(val);
last_color = color;
}
else{
if(color == 0){ //red section
if (last_color == 0) //if last was red it needs to wait
redok.wait();
buff.enqueue(val);
last_color = color; // it must set last color before signaling other writers
blueok.signal(); //blue can now enqueue his value
}else{ //blue section, same as above
if (last_color == 1)
blueok.wait();
buff.enqueue(val);
last_color = color;
redok.signal();
}
}
ok2read.signal(); // reader can now read
}

procedure entry generic_type read(void){
//here waits if needed, then dequeue
if(buff.length() == 0)
ok2read.wait();
generic_type ret = buff.dequeue();

//here signal the one that has been waiting for more time
// it MUST be of the last_color color
if(buff.length() == 0){
color_t tmp=last_color;
last_color = -1;
// last color MUST be set to -1 here because
// if there were writers waiting on ok2write.wait() (full buffer case)
// they woundn't be signaled here, this happens if MAX=1

if (tmp == 1) //
blueok.signal();
else
redok.signal();
}
ok2write.signal();
}

}
</syntaxhighlight>
===Soluzione di FedericoB===
relating to Silas and Marco solution. A bounded buffer is a queue, so i think is wrong to use last_color as head element color when it's used as tail element color.
<source lang="python">
#define MAX

monitor altcobb {
deque buffer
condition waitRed, waitBlue, ok2read, ok2write
altcobb() {
buffer = new Deque()

}
procedure entry void write(colot_t color,generic_type val) {
if (deque.getSize()==MAX) ok2write.wait()
if (buffer.getSize==0) queue.addLast((val,color))
else
if (color==RED)
if (buffer.getLast().color==BLUE)
queue.addLast((val,color))
waitRed.signal()
else
waitBlue.wait()
queue.addLast((val,color))
else
if (buffer.getLast().color==RED)
queue.addLast((val,color))
waitBlue.signal()
else
waitRed.wait()
queue.addLast((val,color))
ok2read.signal()
}
procedure entry generic_type read() {
if (deque.isEmpty()) ok2read.wait()
element = deque.dequeueFirst();
ok2write.signal()
return element;
#needed explanation: after the ok2write.signal() the current process will be put in wait state in the urgent stack,
#but after the woke up process has exited the monitor this process will be woke up and it will return the element.
}
}
</source>

== Esercizio c.2 ==
===Soluzione di Silas===
I semafori garantiscono che A e B vengano eseguiti in maniera sequenziale e che accedano in maniera mutualmente esclusiva ad n, quindi l'unica variazione possibile è il thread di inizio per la sequenza.
Nel caso sia A ad accedere per primo alla CS si ha: n = ((1*2)+2)*3 = 12
Nel caso sia invece B ad accedere per primo alla C si ha: n = (((0*2)+1)*3)+2 = 5
Quindi n = 12 e n = 5 sono i due possibili valori.

ProvaTeorica 2014.02.22

2017-06-12T14:12:57Z

FedericoB: /* Esercizio c.2 */ Aggiunta soluzione

Testo: [http://www.cs.unibo.it/~renzo/so/compiti/2014.02.21.tot.pdf]

==Esercizio c.1==

===Soluzione di Coci===

<syntaxhighlight lang="C">
monitor bbwl {
condition oktowrite;
condition oktolog;
condition oktoread;
int logging = 0;
queue q;

procedure entry write (eltype elem) {
if (q.length() == MAXELEM || logging)
oktowrite.wait();
q.enqueue (elem);
logging = 1;
oktolog.signal();
}

procedure entry eltype log() {
if (q.length == 0)
oktolog.wait();
eltype tmp = q.top();
logging = 0;
oktoread.signal();
return tmp;
}

procedure entry eltype read() {
if (q.length == 0 || logging)
oktoread.wait();
eltype tmp = q.dequeue();
oktowrite.signal();
return tmp;
}
}

</syntaxhighlight>

===Soluzione di Save===

<syntaxhighlight lang="C">

condition oktowrite, oktoread, oktolog ;
queue buffer = MAXELEM ;
queue Llogger ;

monitor bbwl
{
procedure entry write (altype elem)
{
if (buffer.length >= MAXELEM)
oktorite.wait() ;
buffer.enqueue(elem);
oktolog.signal () ;
}

procedur entry logger() # logger deve tenere traccia di tutti i pacchetti transitati mettendoli in una sua memoria.
{
if (buffer.length == 0)
oktolog.wait();
Llogger.enqueue(buffer.front()) # restituisci il valore in testa di buffer e inseriscilo in coda a Llogger
ok toread.signal() ;
}

procedure entry read()
{
if (buffer.length == 0)
oktoread.wait();
buffer.dequeue() # restituisci il valore in testa di buffer e rimuovilo.
oktowrite.signal() ;
}
}
</syntaxhighlight>
save

==Esercizio c.2==

===Soluzione di Coci===

alpha(x,y): <x=4, y=sqrt(x)>

il valore che viene salvato in y è sempre 2, quindi non va bene.

bravo(x,y): <y=sqrt(x), x=4>

<pre>
xi yi xf yf
0 0 4 0
0 1 4 1
1 0 4 1
1 1 4 1
</pre>

il valore iniziale di x viene salvato in y, quindi va bene.

charlie(x,y): <y=sqrt(x), x=4*y>

Anche questo va bene, per le stesse ragioni di bravo.

delta(z,t): <z=z xor t, t=z xor t>
<pre>
zi ti zf tf
0 0 0 0
0 1 1 0
1 0 1 1
1 1 0 1
</pre>
Il valore iniziale di z viene salvato in t, quindi va bene.

===Soluzione di Diego.tului===

alpha: non funziona perché y non andrà mai a 0, quindi non entrerà mai in CS.

bravo: funziona perché quando y va a 0 x rimane 4, e perciò finché x non ritorna 0 la CS è occupata.

charlie: dipende dal valore iniziale di x, perché se all'inizio x = 0 (y = 0, x = 4 * 0 = 0) quindi non ci
sarà mutua esclusione.

delta: dipende dal valore iniziale di t, perché se all'inizio è 0, 0 xor 0 resta sempre 0, ergo come sopra.

Diego

===Soluzione di FedericoB===
alpha assegna valori costanti quindi non è possibile utilizzarla per la test and set in quanto il suo risultato non può essere influenzato da parametri esterni.

bravo(lock,vp) assegna a lock 4 e a y la radice del vecchio lock
Un possibile codice che utilizza bravo è il seguente:
<pre>
int lock=0
process p
int vp;
while(1) {
do {
bravo(lock,vp)
} while (vp==2)
//sezione critica
lock=0
}
</pre>
charlie(lock,vp) assegna a lock 4 moltiplicato per la radice del vecchio lock e a vp la radice del vecchio lock
<pre>
int lock=1
process p
int vp;
while(1) {
do {
charlie(lock,vp)
} while (vp!=1)
//sezione critica
lock=1
}
</pre>
Ho cambiato il valore iniziale del lock per evitare l'effetto assorbente dello zero.
Inoltre ora quando il lock è impostato i processi in attesa avranno un vp completamente differente tra loro quindi ho dovuto utilizzare una diseguaglianza.

delta(z,t)
<pre>
zi ti zf tf
comb1 0 0 0 0
comb2 0 1 1 0
comb3 1 0 1 1
comb4 1 1 0 1
</pre>
Impossibile perchè nessuna delle combinazioni di input e utilizzabile.
La combinazioni 1 e 3 non cambiano il lock e quindi non ci sarebbe mutua esclusione.
Utilizzando le combinazioni 2 e 3 (quindi con vp inizializzato a 1) non ci sarebbe comunque mutua esclusione perchè
se inizializziamo lock a 0 viene messo dalla combinazione 2 a 1 e vp=0, il primo processo ottiene la sezione critica.
Un altro processo si troverebbe il lock impostato a 1 e vp=1 per inizializzazione locale.
Verrebbe quindi utilizzata la combinazione 4 che però riporterebbe il lock a 0 e quindi un terzo processo potrebbe entrare in sezione critica.

==Esercizio g.1==

===Soluzione di Coci===

Sia n=3 il numero di pagine mantenute in memoria

a) 123456789123456789...

MIN = MINNUM
11144777
2225588
333669

b) 145231231231231...

MINNUM

111232123
44444444
5555555

MIN
111111111
44222222
5333333

Alessandro

===Soluzione di Diego.tului===

Sia n=3 il numero di pagine mantenute in memoria

la soluzione di Alessandro secondo noi presenta dei problemi, la integriamo:

a) 1234431432431432431

111444444444444444
222221112221112221
3333333333333333

ProvaTeorica 2014.02.22

2017-06-12T13:04:31Z

FedericoB: Migliorata formattazione pagina

Specifiche phase 2 2016/17

2017-06-10T16:56:13Z

FedericoB: Aggiunto link al documento delle specifiche di progetto

==Documento specifiche==
[http://www.cs.unibo.it/~renzo/so/mikaboo/phase2.pdf Link al documento]
==System call==
=== send ===
int send(struct tcb_t *dest, uintptr_t msg)
a0 = 1, a1 = dest. a2 = msg
=== recv ===
struct tcb_t *recv(struct tcb_t *src, uintptr_t *pmsg)
a0 = 2, a1 = src, a2 = *pmsg

NB: system call 1 e 2 possono essere chiamate solo in kernel mode
system call 0 e' errore
system call non 1 o 2 vengono trasformate in messaggi al thread definito tramite SETSYSMGR se esiste altrimenti msg SETPGMMGR se esiste
altrimenti TERMINATE_THREAD

==servizi della SSI==

solo da kernel mode

{| class="wikitable"
! Nome servizio !! Codice servizio !! Parametri !! Tipo di ritorno !! Note
|-
| GET_ERRNO || 0 || || int || 0 okay
|-
| CREATE_PROCESS || 1 || state_t* || strcut tcb_t* || NULL per errore
|-
| CREATE_THREAD || 2 || state_t* || strcut tcb_t* || NULL per errore
|-
| TERMINATE_PROCESS || 3 || state_t* || ||
|-
| TERMINATE_THREAD || 4 || state_t* || || (se e' l'ultimo thread diventa come TERMINATE_PROCESS)
|-
| SETPGMMGR || 5 || struct tcb_t* ||
| rowspan="3" | SET*MGR restituiscono lo stesso tcb_t, NULL per errore. 
(puà essere chiamato una volta sola per processo, TERMINATE_PROCESS alla seconda chiamata). 
I manager ricevono messaggi che hanno come sender il tcb_t del thread che ha causato la trap, 
un puntatore al suo state_t come payload.
|-
| SETTLBMGR || 6 || struct tcb_t* || ||
|-
| SETSYSMGR || 7 || struct tcb_t* || ||
|-
| GETCPUTIME || 8 || || unsigned int || in microsecondi, relativo al processo
|-
| WAIT_FOR_CLOCK || 9 || || Sospende il thread fino al prossimo tick di pseudo-clock ||
|-
| DO_IO || 10 || DEVICE_REG_ADDR, COMMAND, ... || status
|
*Per Dischi: DEVICE_REG_ADDR, COMMAND, DATA1 (DATA1 e' l'indirizzo per il DMA, settore/testina e cyl, sono in COMMAND)
*Per Nastri: DEVICE_REG_ADDR, COMMAND, DATA1 (DATA1 e' l'indirizzo per il DMA)
*Per Rete: DEVICE_REG_ADDR, COMMAND, DATA1, DATA2 (DATA1 e' l'indirizzo del pacchetto, DATA2 la lunghezza)
*Per Stampante: DEVICE_REG_ADDR, COMMAND, DATA1 (DATA1 contiene il carattere da stampare)
*Per Terminale IN: DEVICE_REG_ADDR, COMMAND
*Per Terminale OUT: DEVICE_REG_ADDR, COMMAND
|-
| GET_PROCESSID || 11 || struct tcb_t* || struct pcb_t * ||
|-
| GET_MYTHREADID || 12 || || struct tcb_t * ||
|-
| GET_PARENTPROCID || 13 || pcb_t* || pcb_t* ||
|}

==Sorgenti di test==
===nucleus.h===
<source lang="C">
#ifndef NUCLEUS_H
#define NUCLEUS_H

#include <stdint.h>
#include "mikabooq.h"

/* Syscall mnemonic values */
#define SYS_SEND 1
#define SYS_RECV 2

/* SSI requests */
#define GET_ERRNO 0
#define CREATE_PROCESS 1
#define CREATE_THREAD 2
#define TERMINATE_PROCESS 3
#define TERMINATE_THREAD 4
#define SETPGMMGR 5
#define SETTLBMGR 6
#define SETSYSMGR 7
#define GET_CPUTIME 8
#define WAIT_FOR_CLOCK 9
#define DO_IO 10
#define GET_PROCESSID 11
#define GET_MYTHREADID 12
#define GET_PARENTPROCID 13

typedef uintptr_t memaddr;
typedef uintptr_t cputime;
typedef uintptr_t devaddr;

extern void* SSI;

#define msgsend(dest, payload) (SYSCALL(SYS_SEND,(unsigned int) (dest),(unsigned int) (payload),0))

#define msgrecv(source, reply) (((struct tcb_t *) SYSCALL(SYS_RECV,(unsigned int) (source),(unsigned int) (reply),0)))

static inline uintptr_t geterrno(void) {
uintptr_t retval;
struct {
uintptr_t reqtag;
} req = {GET_ERRNO};
msgsend(SSI, &req);
msgrecv(SSI, &retval);
return retval;
}

static inline struct tcb_t* create_process(state_t* s) {
struct tcb_t* retval;
struct {
uintptr_t reqtag;
state_t* s;
} req = {CREATE_PROCESS, s};
msgsend(SSI, &req);
msgrecv(SSI, &retval);
return retval;
}

static inline struct tcb_t* create_thread(state_t* s) {
struct tcb_t* retval;
struct {
uintptr_t reqtag;
state_t* s;
} req = {CREATE_THREAD, s};
msgsend(SSI, &req);
msgrecv(SSI, &retval);
return retval;
}

static inline void terminate_process(void) {
struct {
uintptr_t reqtag;
} req = {TERMINATE_PROCESS};
msgsend(SSI, &req);
msgrecv(SSI, NULL);
}

static inline void terminate_thread(void) {
struct {
uintptr_t reqtag;
} req = {TERMINATE_THREAD};
msgsend(SSI, &req);
msgrecv(SSI, NULL);
}

static inline struct tcb_t* setpgmmgr(struct tcb_t* s) {
struct tcb_t* retval;
struct {
uintptr_t reqtag;
struct tcb_t* s;
} req = {SETPGMMGR, s};
msgsend(SSI, &req);
msgrecv(SSI, &retval);
return retval;
}

static inline struct tcb_t* settlbmgr(struct tcb_t* s) {
struct tcb_t* retval;
struct {
uintptr_t reqtag;
struct tcb_t* s;
} req = {SETTLBMGR, s};
msgsend(SSI, &req);
msgrecv(SSI, &retval);
return retval;
}

static inline struct tcb_t* setsysmgr(struct tcb_t* s) {
struct tcb_t* retval;
struct {
uintptr_t reqtag;
struct tcb_t* s;
} req = {SETSYSMGR, s};
msgsend(SSI, &req);
msgrecv(SSI, &retval);
return retval;
}

static inline cputime getcputime(void) {
uintptr_t retval;
struct {
uintptr_t reqtag;
} req = {GET_CPUTIME};
msgsend(SSI, &req);
msgrecv(SSI, &retval);
return retval;
}

static inline void waitforclock(void) {
struct {
uintptr_t reqtag;
} req = {WAIT_FOR_CLOCK};
msgsend(SSI, &req);
msgrecv(SSI, NULL);
}

static inline unsigned int do_io(devaddr device, uintptr_t command, uintptr_t data1, uintptr_t data2) {
uintptr_t retval;
struct {
uintptr_t reqtag;
devaddr device;
uintptr_t command;
uintptr_t data1;
uintptr_t data2;
} req = {DO_IO, device, command, data1, data2};
msgsend(SSI, &req);
msgrecv(SSI, &retval);
return retval;
}

#define do_disk_io(dev, cmd, d1) do_io((dev),(cmd),(d1),0)
#define do_tape_io(dev, cmd, d1) do_io((dev),(cmd),(d1),0)
#define do_net_io(dev, cmd, d1, d2) do_io((dev),(cmd),(d1),(d2))
#define do_printer_io(dev, cmd, d1) do_io((dev),(cmd),(d1),0)
#define do_terminal_io(dev, cmd) do_io((dev),(cmd),0,0)

static inline struct pcb_t* get_processid(struct tcb_t* s) {
struct pcb_t* retval;
struct {
uintptr_t reqtag;
struct tcb_t* s;
} req = {GET_PROCESSID, s};
msgsend(SSI, &req);
msgrecv(SSI, &retval);
return retval;
}

static inline struct pcb_t* get_parentprocid(struct pcb_t* s) {
struct pcb_t* retval;
struct {
uintptr_t reqtag;
struct pcb_t* s;
} req = {GET_PARENTPROCID, s};
msgsend(SSI, &req);
msgrecv(SSI, &retval);
return retval;
}

static inline struct tcb_t* get_mythreadid(void) {
struct tcb_t* retval;
struct {
uintptr_t reqtag;
} req = {GET_MYTHREADID};
msgsend(SSI, &req);
msgrecv(SSI, &retval);
return retval;
}

#endif
</source>
===p2test.c===
<source lang="C">
/*
* Copyright (C) 2017 Renzo Davoli
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/

#include <uARMconst.h>
#include <uARMtypes.h>
#include <libuarm.h>

#include "nucleus.h"

#define QPAGE FRAME_SIZE
#define TERM0ADDR 0x24C

static struct tcb_t* printid;

static void ttyprintstring(devaddr device, char* s) {
uintptr_t status;

for (; *s; s++) {
status = do_terminal_io(device, DEV_TTRS_C_TRSMCHAR | (*s << 8));
switch (status & 0xff) {
case DEV_S_READY:
case DEV_TTRS_S_CHARTRSM:
break;
default:
return;
}
}
}

void tty0out_thread(void) {
uintptr_t payload;
struct tcb_t* sender;

for (;;) {
sender = msgrecv(NULL, &payload);
ttyprintstring(TERM0ADDR, (char*) payload);
msgsend(sender, NULL);
}
}

static inline void tty0print(char* s) {
msgsend(printid, s);
msgrecv(printid, NULL);
}

static inline void panic(char* s) {
tty0print("!!! PANIC: ");
tty0print(s);
PANIC();
}

static struct tcb_t* csid;

static inline void CSIN() {
msgsend(csid, NULL);
msgrecv(csid, NULL);
}

#define CSOUT msgsend(csid, NULL)

void cs_thread(void) {
struct tcb_t* sender;
for (;;) {
sender = msgrecv(NULL, NULL);
msgsend(sender, NULL);
msgrecv(sender, NULL);
}
}

#define SYNCCODE 0x01000010

void p2(), p3(), p4(), p5(), p6(), p7(), p8();

struct tcb_t* testt, * p2t, * p3t, * p4t, * p5t, * p6t, * p7t, * p8t;

static state_t tmpstate;
memaddr stackalloc;

uintptr_t p5sys = 0;
uintptr_t p5send = 0;

void test(void) {
ttyprintstring(TERM0ADDR, "NUCLEUS TEST: starting...\n");
STST(&tmpstate);
stackalloc = (tmpstate.sp + (QPAGE - 1)) & (~(QPAGE - 1));
tmpstate.sp = (stackalloc -= QPAGE);
tmpstate.pc = (memaddr) tty0out_thread;
tmpstate.cpsr = STATUS_ALL_INT_ENABLE(tmpstate.cpsr);
printid = create_thread(&tmpstate);
tty0print("NUCLEUS: first msg printed by tty0out_thread\n");
testt = get_mythreadid();

tmpstate.sp = (stackalloc -= QPAGE);
tmpstate.pc = (memaddr) cs_thread;
csid = create_process(&tmpstate);
tty0print("NUCLEUS: critical section thread started\n");

CSIN();
tmpstate.sp = (stackalloc -= QPAGE);
CSOUT;
tmpstate.pc = (memaddr) p2;
p2t = create_process(&tmpstate);
msgsend(p2t, SYNCCODE);
msgrecv(p2t, NULL);

tty0print("p2 completed\n");

CSIN();
tmpstate.sp = (stackalloc -= QPAGE);
CSOUT;
tmpstate.pc = (memaddr) p3;
p3t = create_process(&tmpstate);
msgrecv(p3t, NULL);

tty0print("p3 completed\n");

CSIN();
tmpstate.sp = (stackalloc -= QPAGE);
CSOUT;
tmpstate.pc = (memaddr) p4;
p4t = create_process(&tmpstate);
msgsend(p4t, NULL);
msgrecv(p4t, NULL);
msgsend(p4t, tmpstate.sp);
msgrecv(p4t, NULL);

if (geterrno() == 0)
panic("p1 wrong errno: recv from p4 should abort, p4 terminated\n");
else {
tty0print("p4 errno ok\n");
}
tty0print("p4 completed\n");

CSIN();
tmpstate.sp = (stackalloc -= QPAGE);
CSOUT;
tmpstate.pc = (memaddr) p5;
p5t = create_process(&tmpstate);
msgsend(p5t, NULL);
msgrecv(p5t, NULL);

if (p5sys == 1) tty0print("p5a usermode sys passup ok\n");
else panic("p5a usermode passup error\n");

if (p5send != 2) tty0print("p5a usermode msg priv kill is ok\n");
else panic("p5a usermode msg priv kill error\n");

CSIN();
tmpstate.sp = (stackalloc -= QPAGE);
CSOUT;
tmpstate.pc = (memaddr) p6;
p6t = create_process(&tmpstate);
msgrecv(p6t, NULL);
tty0print("p6 completed\n");

CSIN();
tmpstate.sp = (stackalloc -= QPAGE);
CSOUT;
tmpstate.pc = (memaddr) p7;
p7t = create_process(&tmpstate);
msgrecv(p7t, NULL);
tty0print("p7 completed\n");
//check total number of thread

CSIN();
tmpstate.sp = (stackalloc -= QPAGE);
CSOUT;
tmpstate.pc = (memaddr) p8;
p8t = create_process(&tmpstate);
msgrecv(p8t, NULL);
tty0print("p8 completed\n");

tty0print("IT'S ALIVE! IT'S ALIVE! THE KERNEL IS ALIVE!\n");
HALT();
}

#define MINLOOPTIME 10000
#define LOOPNUM 10000

void p2(void) {
struct tcb_t* p1t;
uintptr_t value;
cputime cpu_t1, cpu_t2;
int i;

tty0print("p2 started\n");

/* test: GET_MYTHREADID GET_PROCESSID GET_PARENTPROCID */
if (get_mythreadid() != p2t)
panic("p2 get_mythreadid: wrong pid returned\n");

p1t = msgrecv(NULL, &value);
if (value != SYNCCODE)
panic("p2 recv: got the wrong value\n");
if (p1t != testt)
panic("p2 recv: got the wrong sender\n");
if (get_processid(p1t) != get_parentprocid(get_processid(get_mythreadid())))
panic("p2 get_parentprocid get_processid error\n");

/* test: GET_CPUTIME */

cpu_t1 = getcputime();
/* delay for several milliseconds */
for (i = 1; i < LOOPNUM; i++);

cpu_t2 = getcputime();

if ((cpu_t2 - cpu_t1) >= MINLOOPTIME)
tty0print("p2 GET_CPUTIME sounds okay\n");
else
panic("p2 GETCPUTIME sounds faulty\n");

msgsend(p1t, NULL);
msgrecv(p1t, NULL);

terminate_thread();

panic("p2 survived TERMINATE_THREAD\n");
}

#define PSEUDOCLOCK 100000
#define NWAIT 10

void p3(void) {
tty0print("p3 started\n");

cputime time1, time2;
int i;
time1 = getTODLO();
for (i = 0; i < NWAIT; i++) {
waitforclock();
}
time2 = getTODLO();

if ((time2 - time1) < (PSEUDOCLOCK * (NWAIT - 1))) {
panic("WAITCLOCK too small\n");
} else if ((time2 - time1) > (PSEUDOCLOCK * (NWAIT + 1))) {
panic("WAITCLOCK too big\n");
} else {
tty0print("WAITCLOCK OK\n");
}

msgsend(testt, "NULL");

terminate_process();

panic("p3 survived TERMINATE_PROCESS\n");
}

void p4(void) {
static int p4inc = 1;
struct tcb_t* parent;
struct tcb_t* child;
state_t p4childstate;

switch (p4inc) {
case 1:
tty0print("first incarnation of p4 starts\n");
break;
case 2:
tty0print("second incarnation of p4 starts\n");
break;
}
p4inc++;
parent = msgrecv(NULL, NULL);
msgsend(parent, NULL);

msgrecv(NULL, NULL);
/* only the first incarnation reaches this point */

STST(&p4childstate);
CSIN();
p4childstate.sp = (stackalloc -= QPAGE);
CSOUT;
p4childstate.pc = (memaddr) p4;

child = create_process(&p4childstate);
msgsend(child, NULL);
msgrecv(child, NULL);

terminate_process();

panic("p4 survived TERMINATE_PROCESS\n");
}

void p5a();

void p5p(void) {
struct tcb_t* sender;
state_t* state;
short int should_terminate = 0;
for (;;) {
sender = msgrecv(NULL, &state);
switch (CAUSE_EXCCODE_GET(state->CP15_Cause)) {
case EXC_RESERVEDINSTR:
tty0print("p5a got RESERVEDINSTR\n");
should_terminate = 1;
break;
default:
PANIC();
}
if (should_terminate) {
terminate_process();
} else {
msgsend(sender, NULL);
}
}
}

void p5m(void) {
struct tcb_t* sender;
state_t* state;
for (;;) {
sender = msgrecv(NULL, &state);
switch (CAUSE_EXCCODE_GET(state->CP15_Cause)) {
default:
tty0print("p5 mem error passup okay\n");
sender->t_s.pc = (memaddr) p5a;
break;
}
msgsend(sender, NULL);
}
}

void p5s(void) {
uintptr_t retval;
struct tcb_t* sender;
state_t* state;
for (;;) {
sender = msgrecv(NULL, &state);
switch (state->a1) {
case 42:
retval = 42;
break;
case 3:
retval = 0;
break;
default:
retval = -1;
break;
}
state->a1 = retval;
msgsend(sender, NULL);
}
}

#define BADADDR 0xFFFFFFFF

void p5(void) {
state_t mgrstate;
uintptr_t retval = 200;

tty0print("p5 started\n");

STST(&mgrstate);
msgrecv(NULL, &mgrstate.pc);
CSIN();
mgrstate.sp = (stackalloc -= QPAGE);
CSOUT;
mgrstate.pc = (memaddr) p5p;
setpgmmgr(create_thread(&mgrstate));

CSIN();
mgrstate.sp = (stackalloc -= QPAGE);
CSOUT;
mgrstate.pc = (memaddr) p5m;
settlbmgr(create_thread(&mgrstate));

CSIN();
mgrstate.sp = (stackalloc -= QPAGE);
CSOUT;
mgrstate.pc = (memaddr) p5s;

setsysmgr(create_thread(&mgrstate));

/* this should me handled by p5s */

retval = SYSCALL(42, 42, 42, 42);
if (retval == 42)
tty0print("p5 syscall passup okay\n");
else
panic("p5 syscall passup error\n");

*((memaddr*) BADADDR) = 0;

panic("p5 survived mem error");
}

void p5a(void) {
uintptr_t retval = 200;
/* switch to user mode */
setSTATUS((getSTATUS() & STATUS_CLEAR_MODE) | STATUS_USER_MODE);

p5sys = 0;

retval = SYSCALL(3, 2, 1, 0);
if (retval == 0) {
p5sys = 1;
} else {
p5sys = 2;
}

/* this should fail! */
msgsend(SSI, NULL);

p5send = 2;
//infinite loop: this should not be reaached.
// The loop is added in order to allow debug in case of failure (manually check p5send)
for (;;);
}

void p6(void) {
tty0print("p6 started\n");
*((memaddr*) BADADDR) = 0;

panic("p6 survived mem error");
}

void p7(void) {
tty0print("p7 started\n");

SYSCALL(3, 2, 1, 0);

panic("p7 survived syscall without manager");
}

void p8child(), p8grandchild();

void p8(void) {
tty0print("p8 started\n");
state_t childstate;
struct tcb_t* pid = get_mythreadid();
STST(&childstate);
childstate.pc = (memaddr) p8child;
CSIN();
childstate.sp = (stackalloc -= QPAGE);
CSOUT;
msgsend(create_process(&childstate), pid);
CSIN();
childstate.sp = (stackalloc -= QPAGE);
CSOUT;
msgsend(create_process(&childstate), pid);
msgrecv(NULL, NULL);
msgrecv(NULL, NULL);
msgrecv(NULL, NULL);
msgrecv(NULL, NULL);
msgrecv(NULL, NULL);
msgrecv(NULL, NULL);

terminate_process();

panic("p8 survived TERMINATE_PROCESS\n");
}

#define NGRANDCHILDREN 3

void p8child() {
int i;
state_t childstate;
struct tcb_t* ppid;
msgrecv(NULL, &ppid);
for (i = 0; i < NGRANDCHILDREN; i++) {
STST(&childstate);
childstate.pc = (memaddr) p8grandchild;
CSIN();
childstate.sp = (stackalloc -= QPAGE);
CSOUT;
msgsend(create_process(&childstate), ppid);
}
msgrecv(NULL, NULL);

panic("p8child survived parent termination\n");
}

void p8grandchild() {
struct tcb_t* gpid;
msgrecv(NULL, &gpid);
msgsend(gpid, NULL);
msgrecv(NULL, NULL);

panic("p8grandchild survived grandparent termination\n");
}
</source>

Prova pratica 2017.02.17

2017-05-29T17:25:30Z

FedericoB: /* Soluzione di FedericoB */

[[http://www.cs.unibo.it/~renzo/so/pratiche/2017.02.17.pdf link al testo]]
==Esercizio 1==
<source lang="text">
Scrivere un programma ager in grado di invecchiare file.
Il programma deve poter prendere una lista di file come parametri o nessun parametro, nel qual caso invecchierà
tutti I file della directory corrente. “invecchiare” significa predatare il tempo di ultimo accesso e di modifica di 10
giorni.
Esempio:
$ ls -l file
-rw-r--r-- 1 renzo renzo 0 Feb 17 09:07 file
$ ./ager file
$ ls -l file
-rw-r--r-- 1 renzo renzo 0 Feb 7 09:07 file
</source>
===Soluzione di FedericoB===
<source lang="c">
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/stat.h>
#include <utime.h>

int main(int argc, char* argv[]) {
if (argc>1) {
int i=0;
for (i=1;i<argc;i++) {
struct stat structstat;
if (stat(argv[i],&structstat)==0) {
//read last access time
time_t atim = structstat.st_atim.tv_sec;
//read last modification time
time_t mtim = structstat.st_mtim.tv_sec;
atim -= 10 * 24 * 60 * 60;
mtim -= 10 * 24 * 60 * 60;
//create structure for utime
struct utimbuf structutimbuf = {atim, mtim};
//call utime for setting the new date
if (utime(argv[i], &structutimbuf)!=0) {
//if utime failed print errno
perror(NULL);
}
} else {
//if stat failed print errno
perror(NULL);
}
}
}
return 0;
}
</source>
==Esercizio 2==
<source lang='text'>
Completare l’esercizio 1 ponendo una gestione opportuna dei parametri in linea comando che preveda di
poter modificare solo la data di accesso o quella di modifica, di definire il tempo di “invecchiamento” e un help.
Si possono inserire altri parametri ritenuti opportuni.
</source>
===Soluzione di FedericoB===
<source lang=c>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/stat.h>
#include <utime.h>

int main(int argc, char* argv[]) {
int access = 0;
int modification = 0;
int c;
int index = 0;
time_t time = 10 * 24 * 60 * 60;
while ((c = getopt(argc, argv, "amt:h")) != -1) {
switch (c) {
case 'a': access=1; break;
case 'm': modification=1; break;
case 't':
time = strtol(optarg,NULL,10);
break;
case 'h':
case '?':
printf("usage: ager [-a] [-m] [-t time] [file ...]");
default:
abort ();
}
}
for (index = optind; index < argc; index++) {
struct stat structstat;
if (stat(argv[index], &structstat) == 0) {
//read last access time
time_t atim = structstat.st_atim.tv_sec;
//read last modification time
time_t mtim = structstat.st_mtim.tv_sec;
if (!modification || access) {
atim -= time;
}
if (!access || modification) {
mtim -= time;
}
//create structure for utime
struct utimbuf structutimbuf = {atim, mtim};
//call utime for setting the new date
if (utime(argv[index], &structutimbuf) != 0) {
//if utime failed print errno
perror(NULL);
}
} else {
//if stat failed print errno
perror(NULL);
}
}
return 0;
}
</source>
==Esercizio 3==
<source lang='text'>
Il programma deve elencare I file della directory corrente divisi per suffisso (e al termine l’elenco di quelli privi di
suffisso.
es:
.c: primo.c var.c main.c
.h: primo.h const.h
.odt: relazione.odt
makefile README COPYING
</source>
===Soluzione di FedericoB===
<source lang='Python'>
import os
from pathlib import Path

nosuffix = []
suffix = {}
for root, dirs, files in os.walk("."):
for filename in files:
path = Path(filename)
if (len(path.suffix)>0):
suffix.setdefault(path.suffix,[])
suffix[path.suffix].append(filename)
else:
nosuffix.append(filename)
for k in suffix.keys():
print(k, end=": ")
for v in suffix[k]:
print(v,end=" ")
print("")
for v in nosuffix: print(v, end=" ")
</source>

Prova pratica 2017.02.17

2017-05-29T17:25:01Z

FedericoB:

[[http://www.cs.unibo.it/~renzo/so/pratiche/2017.02.17.pdf link al testo]]
==Esercizio 1==
<source lang="text">
Scrivere un programma ager in grado di invecchiare file.
Il programma deve poter prendere una lista di file come parametri o nessun parametro, nel qual caso invecchierà
tutti I file della directory corrente. “invecchiare” significa predatare il tempo di ultimo accesso e di modifica di 10
giorni.
Esempio:
$ ls -l file
-rw-r--r-- 1 renzo renzo 0 Feb 17 09:07 file
$ ./ager file
$ ls -l file
-rw-r--r-- 1 renzo renzo 0 Feb 7 09:07 file
</source>
===Soluzione di FedericoB===
<source lang="c">
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/stat.h>
#include <utime.h>

int main(int argc, char* argv[]) {
if (argc>1) {
int i=0;
for (i=1;i<argc;i++) {
struct stat structstat;
if (stat(argv[i],&structstat)==0) {
//read last access time
time_t atim = structstat.st_atim.tv_sec;
//read last modification time
time_t mtim = structstat.st_mtim.tv_sec;
atim -= 10 * 24 * 60 * 60;
mtim -= 10 * 24 * 60 * 60;
//create structure for utime
struct utimbuf structutimbuf = {atim, mtim};
//call utime for setting the new date
if (utime(argv[i], &structutimbuf)!=0) {
//if utime failed print errno
perror(NULL);
}
} else {
//if stat failed print errno
perror(NULL);
}
}
}
return 0;
}
</source>
==Esercizio 2==
<source lang='text'>
Completare l’esercizio 1 ponendo una gestione opportuna dei parametri in linea comando che preveda di
poter modificare solo la data di accesso o quella di modifica, di definire il tempo di “invecchiamento” e un help.
Si possono inserire altri parametri ritenuti opportuni.
</source>
===Soluzione di FedericoB===
<source lang=c>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/stat.h>
#include <utime.h>

int main(int argc, char* argv[]) {
int access = 0;
int modification = 0;
int c;
int index = 0;
time_t time = 10 * 24 * 60 * 60;
while ((c = getopt(argc, argv, "amt:h")) != -1) {
switch (c) {
case 'a': access=1; break;
case 'm': modification=1; break;
case 't':
time = strtol(optarg,NULL,10);
break;
case 'h':
case '?':
printf("usage: ager [-a] [-m] [-t time] [file ...]");
default:
abort ();
}
}
for (index = optind; index < argc; index++) {
struct stat structstat;
if (stat(argv[index], &structstat) == 0) {
//read last access time
time_t atim = structstat.st_atim.tv_sec;
//read last modification time
time_t mtim = structstat.st_mtim.tv_sec;
if (!modification || access) {
atim -= time;
}
if (!access || modification) {
mtim -= time;
}
//create structure for utime
struct utimbuf structutimbuf = {atim, mtim};
//call utime for setting the new date
if (utime(argv[index], &structutimbuf) != 0) {
//if utime failed print errno
perror(NULL);
}
} else {
//if stat failed print errno
perror(NULL);
}
}
return 0;
}
</source>
==Esercizio 3==
<source lang='text'>
Il programma deve elencare I file della directory corrente divisi per suffisso (e al termine l’elenco di quelli privi di
suffisso.
es:
.c: primo.c var.c main.c
.h: primo.h const.h
.odt: relazione.odt
makefile README COPYING
</source>
===Soluzione di FedericoB===
<source lang='C'>
import os
from pathlib import Path

nosuffix = []
suffix = {}
for root, dirs, files in os.walk("."):
for filename in files:
path = Path(filename)
if (len(path.suffix)>0):
suffix.setdefault(path.suffix,[])
suffix[path.suffix].append(filename)
else:
nosuffix.append(filename)
for k in suffix.keys():
print(k, end=": ")
for v in suffix[k]:
print(v,end=" ")
print("")
for v in nosuffix: print(v, end=" ")
</source>

Prova pratica 2017.02.17

2017-05-29T17:24:30Z

FedericoB: Aggiunta soluzione esercizio 3

[[http://www.cs.unibo.it/~renzo/so/pratiche/2017.02.17.pdf link al testo]]
==Esercizio 1==
<source lang="text">
Scrivere un programma ager in grado di invecchiare file.
Il programma deve poter prendere una lista di file come parametri o nessun parametro, nel qual caso invecchierà
tutti I file della directory corrente. “invecchiare” significa predatare il tempo di ultimo accesso e di modifica di 10
giorni.
Esempio:
$ ls -l file
-rw-r--r-- 1 renzo renzo 0 Feb 17 09:07 file
$ ./ager file
$ ls -l file
-rw-r--r-- 1 renzo renzo 0 Feb 7 09:07 file
</source>
===Soluzione di FedericoB===
<source lang="c">
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/stat.h>
#include <utime.h>

int main(int argc, char* argv[]) {
if (argc>1) {
int i=0;
for (i=1;i<argc;i++) {
struct stat structstat;
if (stat(argv[i],&structstat)==0) {
//read last access time
time_t atim = structstat.st_atim.tv_sec;
//read last modification time
time_t mtim = structstat.st_mtim.tv_sec;
atim -= 10 * 24 * 60 * 60;
mtim -= 10 * 24 * 60 * 60;
//create structure for utime
struct utimbuf structutimbuf = {atim, mtim};
//call utime for setting the new date
if (utime(argv[i], &structutimbuf)!=0) {
//if utime failed print errno
perror(NULL);
}
} else {
//if stat failed print errno
perror(NULL);
}
}
}
return 0;
}
</source>
==Esercizio 2==
<source lang='text'>
Completare l’esercizio 1 ponendo una gestione opportuna dei parametri in linea comando che preveda di
poter modificare solo la data di accesso o quella di modifica, di definire il tempo di “invecchiamento” e un help.
Si possono inserire altri parametri ritenuti opportuni.
</source>
===Soluzione di FedericoB===
<source lang=c>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/stat.h>
#include <utime.h>

int main(int argc, char* argv[]) {
int access = 0;
int modification = 0;
int c;
int index = 0;
time_t time = 10 * 24 * 60 * 60;
while ((c = getopt(argc, argv, "amt:h")) != -1) {
switch (c) {
case 'a': access=1; break;
case 'm': modification=1; break;
case 't':
time = strtol(optarg,NULL,10);
break;
case 'h':
case '?':
printf("usage: ager [-a] [-m] [-t time] [file ...]");
default:
abort ();
}
}
for (index = optind; index < argc; index++) {
struct stat structstat;
if (stat(argv[index], &structstat) == 0) {
//read last access time
time_t atim = structstat.st_atim.tv_sec;
//read last modification time
time_t mtim = structstat.st_mtim.tv_sec;
if (!modification || access) {
atim -= time;
}
if (!access || modification) {
mtim -= time;
}
//create structure for utime
struct utimbuf structutimbuf = {atim, mtim};
//call utime for setting the new date
if (utime(argv[index], &structutimbuf) != 0) {
//if utime failed print errno
perror(NULL);
}
} else {
//if stat failed print errno
perror(NULL);
}
}
return 0;
}
</source>
===Esercizio 3===
<source lang='text'>
Il programma deve elencare I file della directory corrente divisi per suffisso (e al termine l’elenco di quelli privi di
suffisso.
es:
.c: primo.c var.c main.c
.h: primo.h const.h
.odt: relazione.odt
makefile README COPYING
</source>
===Soluzione di FedericoB===
<source lang='C'>
import os
from pathlib import Path

nosuffix = []
suffix = {}
for root, dirs, files in os.walk("."):
for filename in files:
path = Path(filename)
if (len(path.suffix)>0):
suffix.setdefault(path.suffix,[])
suffix[path.suffix].append(filename)
else:
nosuffix.append(filename)
for k in suffix.keys():
print(k, end=": ")
for v in suffix[k]:
print(v,end=" ")
print("")
for v in nosuffix: print(v, end=" ")
</source>

Prova Pratica 2012.05.30

2017-05-28T10:42:17Z

FedericoB: /* Esercizio 1 */ Aggiunta soluzione esercizio 1

==Esercizio 1==
<source lang="text">
Scrivere un minimake, cioe' una versione minimale del programma make.
Questo programma legge il file minimakefile nella directory corrente che ha il seguente formato:
target: comando
Il minimakefile e' scritto in modo che se le dipendenze sono generate da regole del minimakefile queste vengano definite
prima. Ad esempio il minimakefile per compilare ed eseguire il programma hw.c (hello world) sara':
hw.o: gcc -c hw.c
hw: gcc -o hw hw.o
run: ./hw
minimake deve scorrere il minimakefile, se il file indicato come target non esiste esegue il comando (e' vietato l'uso di popen,
system e simili!)
</source>
===Soluzione di Dado e Pierg===
<source lang="c">
#include <stdio.h>
#include <stdlib.h>
#include "s2argv/s2argv.h"
#define MAKEFILE "minimakefile"
#define RUN "run"

int main(int argc, char * argv[]){
FILE *mf;
char *line=NULL;
char *target,*command;
int dim=0;
mf=fopen(MAKEFILE,"r");
if(mf==NULL){
fprintf(stderr,"minimakefile not found!\n");
exit(1);
}
while(getline(&line,&dim,mf)>0){
target=strtok(line,":");
command=strtok(NULL,"\n");
if(strcmp(target,RUN)==0){
system_noshell(command);
}
else if(fopen(target,"r")==NULL){
system_noshell(command);
}
else{
fprintf(stderr,"target %s già esistente: non eseguo\n",target);
}
}
free(line);
fclose(mf);
return 0;
}
</source>
===Soluzione di FedericoB===
<source lang="c">
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <execs.h>

int main(int argc, char* argv[]) {
FILE* file;
if ((file = fopen("minimake", "r")) != NULL) {
char target[256], path[256], args[256];
while (fscanf(file, "%40[^:]: %99[^\n]\n", target, path) != EOF) {
//check if target file exist
if (access(target, F_OK) != 0) {
//if not fork and exec command
int status;
switch (fork()) {
case 0:
execsp(path);
break;
default:
wait(&status);
break;
}
}
}
fclose(file);
} else {
perror(NULL);
}
return 0;
}
</source>

==Esercizio 2==
===Soluzione di Dado e Pierg===
<source lang="text">
la sintassi del minimakefile per l'esercizio2 deve prevedere le dipendenze come il vero makefile.
target: dependence1 dependence2
comando
comando
(come per il makefile il target viene scritto a inizio linea, i comandi hanno un tab come primo carattere)
es per compilare hw.c.
hw.o: hw.c
gcc -c hw.c
hw: hw.o
gcc -o hw hw.o
run: hw
hw
in questo caso occorre eseguire i comandi che seguono la regola di dipendenza solo se il file target non esiste o
se un file indicato come dipendenza e' stato modificato piu' recentemente del target.
</source>

<source lang="c">
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <unistd.h>
#include "s2argv/s2argv.h"
#define MAKEFILE "minimakefile"
#define RUN "run"

int main(int argc, char * argv[]){
FILE *mf;
char *line=NULL;
char *target, *tmp;
int dim = 0;
int a = b = 0;
struct stat st_target, st_tmp;

mf=fopen(MAKEFILE,"r");
if(fd==NULL){
fprintf(stderr,"minimakefile not found!\n");
exit(1);
}
while(getline(&line,&dim,mf)>0){
if (line[0] == "\t") {
if(a || b){
system_noshell(line + 1);
}
}
else{
a = b = 0;
target = strtok(line, ":")
if(fopen(target,"r")==NULL){
a = 1;
}
else if(strcmp(target,RUN)==0){
char *command = strtok(NULL, "\n");
system_noshell(command);
}
else {
stat(target, &st_target);
while ((tmp = (strtok(NULL, " "))!=NULL){
stat(tmp, &st_tmp);
if (st_tmp.st_mtime > st_target.st_mtime ) {
b = 1;
break;
}
}
}
}
}
free(line);
fclose(fd);
return 0;
}
</source>
==Esercizio 3==
<source lang="text">
Lo script o il programma python prende il nome di una directory come parametro e deve listare i file nella directory che hanno
un file corrispondente con nome scritto al contrario (il file ailati deve essere nella lista solo se nella directory c'e' anche italia, i
palindromi devono essere listati una sola volta).
</source>
===Soluzione di Pierg===
<source lang ="python">
import sys, os

lines = []
directory = sys.argv[1]

for file in os.listdir(directory):
lines.append(file)

for el in lines:
for le in lines:
if el[::-1] == le:
print el
</source>
===Soluzione di Dado===
<source lang="bash">
#! /bin/bash
cd $1
files=`ls`
ls > /tmp/tmp.txt
rev /tmp/tmp.txt > /tmp/tmp2.txt
for file in $files; do
grep $file /tmp/tmp2.txt
done
rm /tmp/tmp.txt
rm /tmp/tmp2.txt
</source>

ProvaPratica 2011.05.30

2017-05-27T14:33:20Z

FedericoB: Aggiunta soluzione es 1

[http://www.cs.unibo.it/~renzo/so/pratiche/2011.05.30.pdf Link to exam]

==Esercizio 1==
<source lang="text">
Scrivere due programmi in modo che i parametri passati al
primo vengano stampati dal secondo. La comunicazione deve avvenire tramite una shared memory realizzata
con la chiamata POSIX shm_open, la sincronizzazione tramite segnali. Viene attivato per primo il programma
ricevente. (anche i pid dei processi possono venir scambiati attraverso la shared memory!).
Es: scrivere in un terminale:
$./receiver
l'esecuzione di “receiver rimane in attesa”. in un secondo terminale scrivere:
$./sender a bb ccc
nel primo deve comparire
./sender
a
bb
ccc
</source>
===Soluzione di Gab===
sender.c

<syntaxhighlight lang="C">
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
#include <signal.h>

#define COMMUNICATION_SIGNAL 25
#define MAXIMUM_LENGTH 4096

#define PID_LENGTH 10

int main(int argc,char *argv[])
{
int sharedFD = shm_open("/sharedPID", O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
if(!sharedFD)
return;
ftruncate(sharedFD,sizeof(char)*PID_LENGTH);
char *sharedVariable = mmap(NULL,sizeof(char)*PID_LENGTH,PROT_READ | PROT_WRITE,MAP_SHARED,sharedFD,0);
int effectivePID = atoi(sharedVariable);
int sharedParametersFD = shm_open("/sharedParameters", O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
if(!sharedParametersFD)
return;
ftruncate(sharedParametersFD,sizeof(char)*MAXIMUM_LENGTH);
char *parameters = mmap(NULL,sizeof(char)*MAXIMUM_LENGTH,PROT_READ | PROT_WRITE,MAP_SHARED,sharedParametersFD,0);
char parametersToPass[MAXIMUM_LENGTH];
int i;
for(i=0;i<MAXIMUM_LENGTH;i++)
parametersToPass[i]='\0';
for(i=0;i<argc;i++)
{
strcat(parametersToPass,argv[i]);
strcat(parametersToPass,"\n");
}
strcpy(parameters,parametersToPass);
kill(effectivePID,COMMUNICATION_SIGNAL);
return 0;
}
</syntaxhighlight>

receiver.c

<syntaxhighlight lang="C">
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <signal.h>
#include <fcntl.h>
#include <string.h>

#define COMMUNICATION_SIGNAL 25

#define MAXIMUM_LENGTH 4096

#define PID_LENGTH 10

static void signalHandler (int sig, siginfo_t *siginfo, void *context)
{
int sharedFD = shm_open("/sharedParameters", O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
if(!sharedFD)
return;
ftruncate(sharedFD,sizeof(char)*MAXIMUM_LENGTH);
char *parameters = mmap(NULL,sizeof(char)*MAXIMUM_LENGTH,PROT_READ | PROT_WRITE,MAP_SHARED,sharedFD,0);
printf("Parameters: %s",parameters);
exit(0);
}

int main(int argc,char *argv[])
{
int sharedFD = shm_open("/sharedPID", O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
if(!sharedFD)
return;
char *currentPIDToPass;
asprintf(&currentPIDToPass,"%d",getpid());
ftruncate(sharedFD,sizeof(char)*PID_LENGTH);
char *sharedVariable = mmap(NULL,sizeof(char)*PID_LENGTH,PROT_READ | PROT_WRITE,MAP_SHARED,sharedFD,0);
strcpy(sharedVariable,currentPIDToPass);
struct sigaction signalStruct;
signalStruct.sa_sigaction = &signalHandler;
sigaction(COMMUNICATION_SIGNAL,&signalStruct,NULL);
while(1){}
return 0;
}
</syntaxhighlight>

Gab
===Soluzione di Dado e Pierg===

sender.c
<source lang="c">
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>

int main(int argc, char * argv[]){
int fd,i;
fd=shm_open("/shared",O_RDWR,'w');
if(fd==-1){
fprintf(stderr,"Error while opening the shared memory\n");
}
for(i=0;i<argc;i++){
write(fd,argv[i],sizeof(argv[i]));
write(fd,"\n",1);
}
return 0;
}
</source>

receiver.c
<source lang="c">
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#define MAXLENGTH 1024

int main(int argc, char * argv[]){
int fd;
ssize_t dim;
char buff[MAXLENGTH];
fd=shm_open("/shared",O_RDWR,'r');
while((dim=read(fd,&buff,MAXLENGTH))){
write(stdout,buff,MAXLENGTH);
}
return 0;
}
</source>
Manca la sincronizzazione tramite segnali --[[User:FedericoB|FedericoB]] ([[User talk:FedericoB|talk]]) 16:33, 27 May 2017 (CEST)

===Soluzione di FedericoB===
receiver
<source lang="C">
#define _GNU_SOURCE

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <signal.h>
#include <fcntl.h>
#include <string.h>

#define MAXSIZE 4096

int main(int argc, char* argv[]) {
int sharedFD;
printf("pid = %d\n", getpid());
//create shared memory object
if ((sharedFD = shm_open("/sharedPID", O_CREAT | O_RDWR, S_IRUSR | S_IWUSR)) != -1) {
//set size of shared memory object
if (ftruncate(sharedFD, MAXSIZE) == 0) {
//create a memory mapping with sharedVariable and the shared memory object
#define OFFSET 0
#define ADDRESS NULL
char* sharedVariable = mmap(ADDRESS, MAXSIZE, PROT_READ | PROT_WRITE, MAP_SHARED, sharedFD, OFFSET);
if (sharedVariable != MAP_FAILED) {
sprintf(sharedVariable, "%d\n", getpid());
sigset_t mask;
//initialize signal mask
sigemptyset(&mask);
sigaddset(&mask, SIGUSR1);
//block default handler for SIGUSR1
sigprocmask(SIG_BLOCK, &mask, NULL);
int sig;
//wait for a SIGURS1
sigwait(&mask, &sig);
printf("%s\n", sharedVariable);
shm_unlink("/sharedPID");
return 0;
} else {
perror(NULL);
}
} else {
perror(NULL);
}
} else {
perror(NULL);
}

}
</source>
sender
<source lang="c">
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
#include <signal.h>

#define MAXSIZE 4096

int main(int argc,char *argv[]) {
int sharedFD;
//create shared memory object
if ((sharedFD = shm_open("/sharedPID", O_CREAT | O_RDWR, S_IRUSR | S_IWUSR)) != -1) {
ftruncate(sharedFD, MAXSIZE);
#define OFFSET 0
#define ADDRESS NULL
char* sharedVariable = mmap(ADDRESS, MAXSIZE, PROT_READ | PROT_WRITE, MAP_SHARED, sharedFD, OFFSET);
int effectivePID = atoi(sharedVariable);
printf("pid = %d\n",effectivePID);
shm_unlink("/sharedPID");
int i;
for (i=0;i<MAXSIZE;i++) sharedVariable[i]='\0';
for (i = 1; i < argc; i++) {
strcat(sharedVariable, argv[i]);
strcat(sharedVariable, " ");
}
kill(effectivePID, SIGUSR1);
return 0;
} else {
perror(NULL);
}
}
</source>

Prova pratica 2017.02.17

2017-05-27T08:19:20Z

FedericoB: Aggiunta soluzione esercizio 2

Prova pratica 2017.02.17

2017-05-26T12:58:05Z

FedericoB: Creata pagina con soluzione es 1

Prove pratiche

2017-05-26T12:52:42Z

FedericoB: Aggiunto link prova pratica 2017.02.17

''Qui troverete alcune prove teoriche pratiche (laboratorio), in modo da poter discutere sull'elaborato''

''Le prove sono svolte da studenti e servono come base per la discussione. Le soluzioni possono essere errate''

[[Prova pratica 2017.02.17]]

[[Prova pratica 2017.01.17]]

[[Prova pratica 2016.09.13]]

[[Prova pratica 2016.05.31]]

[[Prova pratica 2015.05.20]]

[[Prova pratica 2015.01.21]]

[[Prova pratica 2014.09.25]]

[[Prova pratica 2014.07.17]]

[[Prova Pratica 2014.07.02]]

[[Prova Pratica 2014.06.17]]

[[Prova pratica 2014.05.29]]

[[Prova Pratica 2014.02.20]]

[[ProvaPratica 2014.01.23]]

[[ProvaPratica 2013.09.13]]

[[ProvaPratica 2013.07.18]]

[[ProvaPratica 2013.06.21]]

[[ProvaPratica 2013.05.29]]

[[ProvaPratica 2013.02.15]]

[[ProvaPratica 2013.01.25]]

[[ProvaPratica 2012.09.19]]

[[ProvaPratica 2012.07.17]]

[[ProvaPratica 2012.06.20]]

[[Prova Pratica 2012.05.30]]

[[ProvaPratica 2011.09.12]]

[[Prova Pratica 2011.06.22]]

[[ProvaPratica 2011.05.30]]

[[ProvaPratica 2011.01.19]]

[[ProvaPratica 2010.07.19]]

[[ProvaPratica_2010.07.12]]

[[ProvaPratica 2010.02.03]]

[[ProvaPratica 2009.09.23]]

[[ProvaPratica 2009.06.23]]

[[ProvaPratica 2009.02.12]]

[[ProvaPratica 2009.01.15]]

[[ProvaPratica 2005.02.10]]

[[Prova pratica 2002.01.24]]

Prove pratiche

2017-05-26T11:53:44Z

FedericoB: Correct chronological order of tests

''Qui troverete alcune prove teoriche pratiche (laboratorio), in modo da poter discutere sull'elaborato''

''Le prove sono svolte da studenti e servono come base per la discussione. Le soluzioni possono essere errate''

[[Prova pratica 2017.01.17]]

[[Prova pratica 2016.09.13]]

[[Prova pratica 2016.05.31]]

[[Prova pratica 2015.05.20]]

[[Prova pratica 2015.01.21]]

[[Prova pratica 2014.09.25]]

[[Prova pratica 2014.07.17]]

[[Prova Pratica 2014.07.02]]

[[Prova Pratica 2014.06.17]]

[[Prova pratica 2014.05.29]]

[[Prova Pratica 2014.02.20]]

[[ProvaPratica 2014.01.23]]

[[ProvaPratica 2013.09.13]]

[[ProvaPratica 2013.07.18]]

[[ProvaPratica 2013.06.21]]

[[ProvaPratica 2013.05.29]]

[[ProvaPratica 2013.02.15]]

[[ProvaPratica 2013.01.25]]

[[ProvaPratica 2012.09.19]]

[[ProvaPratica 2012.07.17]]

[[ProvaPratica 2012.06.20]]

[[Prova Pratica 2012.05.30]]

[[ProvaPratica 2011.09.12]]

[[Prova Pratica 2011.06.22]]

[[ProvaPratica 2011.05.30]]

[[ProvaPratica 2011.01.19]]

[[ProvaPratica 2010.07.19]]

[[ProvaPratica_2010.07.12]]

[[ProvaPratica 2010.02.03]]

[[ProvaPratica 2009.09.23]]

[[ProvaPratica 2009.06.23]]

[[ProvaPratica 2009.02.12]]

[[ProvaPratica 2009.01.15]]

[[ProvaPratica 2005.02.10]]

[[Prova pratica 2002.01.24]]

Lezioni Anno Accademico 2016/17

2017-05-16T14:03:30Z

FedericoB: /* Lezione del 16 maggio 2017 */ Aggiunti argomenti trattati

''scrivete qui idee, riassunti dei concetti espressi, commenti approfondimenti sulle lezioni.''

== Lezione del 23 settembre 2016 ==

'''YY'''

* Presentazione del corso.
* Strumenti del corso: web, wiki.mailing list
* Indice dei contenuti
* Prove di esame (Scritto, Prova Pratica, Progetto).

* Hardware Software
* Informatica
* Informazione/Dato
* Rivoluzione digitale (secondo rinascimento, Terza rivoluzione Industriale).
* Software Libero

== Lezione del 27 settembre 2016 ==

'''OS:Y'''

* '''Organizzazione (martedi' vs. venerdi')'''
In genere la lezione del martedì sarà più teorica mentre quella del venerdì più orientata agli aspetti pratici di laboratorio. Questa suddivisione potrebbe cambiare in quanto qualche martedì verrà saltato.
* '''Università'''
Università = studenti + docenti
* '''Digitale/Analogico'''
Digit significa cifra. Nell'informatica è fondamentale il passaggio dal continuo al discreto.
* '''Binario/Decimale'''
Nei calcolatori l'informazione è memorizzata utilizzando il sistema binario ...
(''in quanto in passato i relè consentivano di avere due stati: " 1 e 0 "'': è impreciso, qualcuno sa dare una definizione migliore? [[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 12:00, 29 September 2016 (CEST)) 
In quanto è molto semplice implementare le operazioni aritmetiche con dei circuiti elettronici utilizzando la codifica binaria. Per esempio è possibile creare un [https://it.wikipedia.org/wiki/Half-adder circuito] che somma due bit con riporto con solo due porte logiche. [[User:FedericoB|FedericoB]] ([[User talk:FedericoB|talk]]) 17:05, 29 September 2016 (CEST)
* '''I linguaggi e i problemi dell'Informatica'''
**Processing dell'informazione (Linguaggi di programmazione)
**Comunicazione (Il problema che i dati che mi servono sono in un altro luogo) (Linguaggi dei protocolli di rete, che però sono dei linguaggi temporizzati)
**Memorizzazione (Il problema che i dati mi serviranno in futuro) (Linguaggio del formato dei dati)
* '''Conoscenze a lungo, medio e breve termine nell'Informatica.'''
**BREVE: tecnologia, determinati programmi di sviluppo.
**MEDIO: singoli linguaggi, singoli OS, protocolli di comunicazione.
**LUNGO: algoritmi, informatica teorica, fondamenti costruttivi di reti e di OS.

* '''Cos'è una distribuzione'''
E' un antologia di applicazioni e librerie in modo che siano compatibili tra loro.

* '''Sistema Operativo: perché'''
Un sistema operativo è un programma che controlla l’esecuzione di programmi applicativi e agisce come interfaccia tra le applicazioni e l’hardware del calcolatore. 
E' uno strumento software complesso ed implementabile in diversi modi (monolitico, microkernel, etc.). I microcontroller non hanno OS.
Permette: contabilità delle risorse (consente a sua volta attività di benchmarking); continuità dei servizi; controllo errori
(programmi, dispositivi); multiuser (gli utenti hanno diversi diritti e proprietà sulle risorse); protezione delle attività dei
processi; astrazione file system.
* '''Struttura a livelli (layer)'''

---------------
---------------
---------------
OS
---------------L'
hw
---------------L

Consente di: separare la complessità, di avere portabilità.
Ogni livello rappresenta un cambio di linguaggio.
Più aggiungiamo livelli più aumenta il livello di astrazione.
* '''Programma/processo'''
Algoritmo: sequenza finita di istruzioni non ambigue, atta a risolvere un problema.

Programma: traduzione degli algoritmi in un linguaggio di programmazione.

Processo: istanza esecutiva di un programma. Il programma è testo statico, quando viene eseguito diviene processo. Possiamo avere
uno stesso programma in esecuzione su più processi (e.g apertura di più terminali che eseguono un editor di testo).

System call: richieste di processi al OS. e.g. printf (visto nel codice compilato in assembly tramite gcc -s), invoca write().
vi è una sequenza di azioni del tipo: richiesta di stampa al kernel --> attesa --> risposta.
* '''Storia dell'Informatica prima dei transistor'''

La storia dei calcolatori non ha un inizio preciso. Nel 1900 venne trovato sul relitto di una nave greca risalente al II secolo a.C un meccanismo in grado di calcolare i movimenti degli astri, si ipotizza con una sorprendente meccanica. Oggi questo sistema viene conosciuto come Macchina di Anticitera. Negli ultimi anni di ricerche archeologiche e storiche è venuta sempre più in superficie una vena pionieristica nel mondo classico per quanto riguarda lo studio sul calcolo automatizzato e addirittura di automi (si veda Erone di Alessandria). Ma facciamo un salto in avanti di qualche secolo... 
Già nel XVII secolo Pascal teorizza e mette in pratica uno strumento in grado di addizionare e sottrarre, e nel 1672 G.W. von Leibniz lo perfeziona con l'aggiunta della moltiplicazione e della divisione. Ma è solamente nei primi anni del 1800 che entra in scena la macchina analitica di Babbage. Estremamente complessa, la macchina era dotata di un sistema di input e di elaborazione dati e di un sistema di output. Ed è con Babbage che nascono le schede perforate. La macchina analitica venne presentata per la prima volta in Italia, durante un convegno torinese del 1840. Tra i vari collaboratori scientifici alla macchina è da annotare la presenza di Luigi Federico Menabrea, che tra le altre cose fu Ministro della Marina Militare, ingegnere e Presidente del Consiglio dei Ministri del Regno d'Italia (1867-1869). Il primo vero programmatore della storia, collaboratrice di Babbage, è Ada Lovelace (figlia del poeta Lord Byron!): progettò un algoritmo in grado di elaborare i numeri di Bernulli. 
Nel 1896 viene fondata la Tabulating Machine Company (futura IBM) e agli albori del '900, vari scienziati (trai quali Thomas Edison e Guglielmo Marconi) portarono avanti gli studi sulla valvola termoionica, elemento indispensabile dei primi calcolatori elettronici. La valvola incrementò vertiginosamente i tempi di calcolo ma l'estrema fragilità della stessa causò una serie di problematiche che si risolsero solamente con l'entrata in gioco del transistor.

== Lezione del 30 settembre 2016 ==

'''YC'''

(Storia dopo l'avvento del transistor)

Tre innovazioni indipendenti:
* Multitasking: Inizialmente ideato per mantenere la CPU occupata con altri processi mentre si faceva Input/Output. Permette di dare l'idea al utente di poter eseguire più processi contemporaneamente anche se questi in realtà sono eseguiti dalla cpu in modo intervallato. Ci sono certi computer che hanno più esecutori e quindi possono realmente eseguire multipli processi contemporaneamente.
* Supporto Multiuser
* Interattività:l'interazione con l'utente cambia il flusso del programma.

Queste tre proprietà sono ortogonali quindi possono esistere nei sistemi varie combinazioni di queste.

Iniziano anche a separarsi i ruoli tra programmatori e utenti.Prima i computer venivano utilizzati solo da chi creava programmi ora anche da chi li utilizza senza avere le conoscenze per crearli.

Il Time Sharing.

Sistemi Paralleli (SIMD/MIMD)
Sistemi Real Time

Dal 1969: UNIX.

Il linguaggio C e la portabilità dei sistemi operativi.
Caratteristiche del linguaggio C:
* grande controllo sul codice generato
* costrutti per l'elaborazione a basso livello
* supporto per la programmazione strutturata
* linguaggio "leggero": poche parole chiave, I/O gestito tramite librerie
* Il compilatore C è scritto in C.

Portabilità di un compilatore. I cross-compiler.

Il comando UNIX cc (o gcc): un comando unico per attivare l'intera toolchain per generare un eseguibile.

Il punto e virgola trasforma espressioni in istruzioni (terminatore).

1975? l'avvento dei personal computer. (in realtà il primo PC forse e' la Perrottina Olivetti del 1964).

Compiti a casa:
Portare esperimenti in C ritenuti "difficili".

[[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 10:41, 1 October 2016 (CEST)

== Lezione del 7 ottobre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7TzJXUTJZM3RBUlE 7\10\16]
* '''Esempi di programmi in linguaggio C'''
Abbiamo commentato i programmi dal 1.1 al 1.7 che si possono trovare in questa [[2016-17_Programmi_C|pagina]].
* '''Economia Push/Economia Pull'''
Nell'economia push si basa la produzione sulla previsione di domanda e la si cerca di aumentare tramite la pubblicità. Questa è stata la principale metodologia utilizzata nei secoli scorsi.
Al giorno d'oggi si sta facendo avanti un differente approccio chiamato "economia pull" dove la produzione è basata sulla domanda effettiva. Per esempio per richiedere un finanziamento per l'economia push l'approccio comune è tramite una banca a cui si chiede un prestito in base alle previsioni di ricavo. Invece nell'economia pull è esemplare il fenomeno del crowdfounding dove si riceve un finanziamento dalla "folla" cioè da un gruppo di persone che dona una piccola parte di denaro ciascuna in base al reale interesse per il prodotto/servizio.
* '''Sistemi Operativi e parallelismo'''
Più processi si dicono in esecuzione concorrente quando accedono a risorse condivise.
Un programma è multithread quando tutti i thread condividono la stessa memoria. Ogni thread deve avere un suo stack.
La concorrenza si studia in particolare in sistemi operativi in quanto un sistema operativo multitasking è un sistema concorrente.
Concorrenza di processi in architetture SMP (Symmetric multiprocessor system) e non. (RD: non mi pare di aver spiegato cosa sia l'SMP) 
Simulazione del fenomeno della '''race condition'''. Si ha '''race condition''' quando un programma concorrente può puo' produrre diversi risultati se eseguito piu' volte per colpa della diversa evoluzione temporale delle elaborazioni. 
Per risolvere questo dovremmo raggruppare le istruzioni in ''sezioni critiche'' (sequenze inscindibili di istruzioni che devono essere eseguite come se fossero atomiche, tutta la sequenza o niente).
* '''Architettura a livelli e virtualizzazione'''
Dato un A e un A’ e riusciamo a usare A’ come A, allora A’ lo possiamo chiamare A virtuale.
L'idea che alla base delle macchine virtuali è di creare un interprete di un ISA differente o uguale a quello del sistema in modo da virtualizzare una reale macchina hardware e quindi poterla usare per gli stessi scopi di una macchina reale. E' quindi possibile, per esempio, installare sistemi operativi su hardware virtuale. 
L'insieme dei componenti hardware virtuali e il software installato su di questi prende il nome di ''macchina virtuale''.
Uno dei principali vantaggi, oggi molto utilizzato in ambito cloud, è quello di poter suddividere facilmente risorse hardware fisiche, per esempio spazio su disco e potenza di elaborazione, tra macchine virtuali differenti.
* '''Laboratorio di cross-compiling'''
Nel ultima parte della lezione abbiamo fatto un esperimento sulla portabilità dei compilatori. 
Abbiamo a disposizione un linguaggio ad alto livello che chiameremo L, due interpreti hw0 e hw1 per linguaggi a basso livello che chiameremo lhw0 e lhw1 e infine due compilatori L->lhw0 uno scritto in python e l'altro in L. 
Se compiliamo con il compilatore scritto in python (abbiamo un interprete python installato sulla macchina che stiamo utilizzando) il compilatore scritto in L otteniamo un compilatore scritto in lhw0 L->lhw0. 
Se ora modifichiamo il compilatore scritto in L L->lhw0 in modo che crei codice per hw1 (basta modificare gli indici numerici delle istruzioni) otteniamo un compilatore in L L->lhw1. Se lo compiliamo con il compilatore L->lhw0 otteniamo un ''cross-compiler'' scritto in lhw0 L->lhw1, cioè un compilatore che crea codice eseguibile su una macchina diversa da quella attuale. 
Se ora utilizziamo il cross compiler L->lhw1 per compilare il compilatore scritto in L L->hw1 otteniamo invece un compilatore che può essere eseguito su hw1. 
A questo punto su hw1 potremmo utilizzare l'ultimo compilatore creato per compilare sempre il compilatore scritto in L L->hw1 ma vedremo che otterremo sempre lo stesso file perché avremo raggiunto il limite.
 
Il materiale per poter replicare l'esperimento sulla portabilità dei compilatori è [http://www.cs.unibo.it/~renzo/so/tools/portability3.tgz qui].
[[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 13:42, 8 October 2016 (CEST)

== Lezione del 11 ottobre 2016 ==
*'''C'''
<syntaxhighlight lang=C>
#include <stdio.h>

void dump (void* f, size_t len){ //size_t is the sizeof() return type
unsigned char *s = f;
size_t i;
for (i = 0; i < len; i++)
printf("%02x ",s[i]); //%02x means print at least 2 digits and add 0's if there are less
printf("\n");
}

int main(){

int v[] = {1, 2, 3, 4}; //v is (int*) 0x32ef...
v[2] = 42; //*((int*) 0x32ef) + 2 = 42, moves the address by 2 "positions", aka 4+4 bytes
v[2] = 0x33;//(int*) 0x32ef.. = 0x33 (i.e.) 4 = 42

char s[] = "ciao";
int t[] = {0x63, 0x69, 0x61, 0x6f, 0x00}; //ciao in ASCII hex. if int OUT:'c'. if char OUT:"ciao"
char u[] = {99, 105,97, 111, 0 }; //ciao in ASCII dec. OUT:"ciao"

char *q = "ciao";
char *w = "mare";

printf("%s\n", s);
printf("%s\n", t);
printf("%s\n", u);

dump(s, sizeof(s));
dump(t, sizeof(t));
dump(q, sizeof(*q)); //*q size is 1B (it points to 1 char). OUT: 63('c')
dump(q, sizeof(q)); //q size is 8B. OUT: 5B of "ciao" + 3B of contiguous string "mare"
}
</syntaxhighlight>

OUTPUT:
<pre>
ciao
c
ciao
63 69 61 6f 00
63 00 00 00 69 00 00 00 61 00 00 00 6f 00 00 00 00 00 00 00 //int are 4B, char 1B, so we have empty bytes.
Little endian pattern is evident. %s allow to print untill the first null, so printf prints just 'c' with int declaration of t[]
63
63 69 61 6f 00 6d 61 72 // 6d = m, 61 = a, 72 = r.
</pre>

* '''Assioma di finite progress.'''
"Tutto è vero purchè ogni statement abbia durata sconosciuta, ma finita"
* '''Modalità di concorrenza.'''
1- Inconsapevolmente concorrenti: ogni processo elabora ciò per cui è stato creato. Il kernel si occupa di coordinazione e comunicazione.

2- Indirettamente concorrenti: processi che accedono a file condivisi.

3- Consapevolmente concorrenti: il programma ha diversi processi in esecuzione.
*''' Convenzioni usate nel corso (e negli esami) relative alle istruzioni atomiche'''
Le istruzioni atomiche vengono compiute in modo indivisibile, garantendo che l'azione non interferisca con altri processi durante la sua esecuzione.
Vengono rappresentate nel seguente modo:
<pre>
<istruzione atomica>
</pre>
Anche gli statement sono istruzioni atomiche(escluso il caso long long).
*''' Proprieta' di Safety e Liveness'''
-Safety: se il programma evolve, evolve bene(S)

"''Something good'' happens"

-Liveness: il programma va avanti(L)

"''Something eventually'' happens"

* '''Problema del consenso.'''
Il problema è così definito: ci sono n processi, ognuno propone un valore. Al termine tutti i processi devono accordarsi su di 1 dei valori proposti.Il suddetto problema è risolvibile se e solo se vengono rispettate le seguenti proprietà (2 di Safety + 1 di Liveness)

Proprietà:

S(1)- Tutti i processi devono ritornare lo stesso valore

S(2)- Ogni processo corretto decide uno tra i valori proposti

L(1)- Ogni processo corretto deve dare una risposta

w/o S(1): f(x) = x

w/o S(2): f(x) = 42

w/o L(1): f(x) = while(1)

*w/o = without

* '''Problemi delle elaborazioni concorrenti. Prima definizione (non formale) di Deadlock e Starvation'''
Introduzione alla notazione per la rappresentazione dei processi concorrenti

ESEMPIO 1.0

process p {
...
...
}

process q {
...
...
}

Due processi eseguiti in concorrenza.

...
cobegin
...
//
...
//
...
coend

cobegin e coend indicano la sezione di codice con le istruzioni (rappresentate da "..." e separate da "//")che verranno eseguite in concorrenza.

ESEMPIO 1.1 - Merge sort
cobegin
sort(v[1 : N])
//
sort(v[N : N])
//
merge(v[1 : N]), v[N : M])
coend

Se isoliamo le istruzioni senza considerare cobegin e coend, lo pseudocodice è corretto.
Se consideriamo anche cobegin e coend il programma esegue la funzione di merge() in concorrenza con le due chiamate a sort(), utilizzando risorse in comune e pertanto cercando di ordinare elementi non ancora ordinati nelle due metà dell'array.
Se spostiamo l'invocazione di merge al di fuori della sezione cobegin ... coend, lo pseudocodice (vedi in basso) è corretto.

cobegin
sort(v[1 : N])
//
sort(v[N : N])
coend
merge(v[1 : N]), v[N : M])

In particolare nella programmazione concorrente si devono affrontare due problemi che riguardano la liveness, parliamo di deadlock e starvation.

'''DEADLOCK''': uno o più processi non possono continuare l'esecuzione perchè ognuno di essi è in attesa che gli altri facciano qualcosa

ESEMPIO 1.2

process p {
while 1:
prendi a
prendi b
calcola f(a,b)
lascia a
lascia b
}

process q {
while 1:
prendi a
prendi b
calcola f(a,b)
lascia a
lascia b
}

Supponiamo di invertire l'ordine di prendi a e prendi b nel processo p. Dopo che entrambi i processi eseguono la prima istruzione lo scenario che si sviluppa è il seguente: al processo p serve la risorsa a, presa dal processo q, al quale servirebbe la risorsa b, presa dal processo p. I processi aspettano a vicenda che uno rilasci la risorsa che possiede l'altro. Risorsa necessaria ad entrambi i processi per eseguire l'istruzione (f(a,b)) che le richiederebbe entrambe. I processi sono deadlocked.

'''STARVATION''': quando un processo attende una risorsa indefinitamente, e questa non gli viene mai allocata

ESEMPIO 1.3
process p {
while 1:
prendi a
calcola f(a)
lascia a
}

process q {
while 1:
prendi a
calcola f(a)
lascia a
}

Supponiamo che i processi per realizzare "prendi a" verifichino la disponibilità di a tramite polling (provando ripetutamente se a è libero). Il processo q può essere sfortunato e non riuscire mai ad avere accesso ad a (tutte le volte che cerca di "prenderlo" lo troverà impegnato da p). Il processo q è in starvation.

ESEMPIO 1.4
"Supponiamo di avere tre processi (P1, P2, P3) i quali richiedono periodicamente accesso alla risorsa R. Consideriamo la situazione nella quale P1 è in possesso della risorsa, e sia P2 che P3 attendono per quella risorsa. Quando P1 esce dalla sua sezione critica, a P2 o P3 dovrebbe essere permesso l'accesso a R. Assumiamo che il SO garantisca l'accesso a P3 e che P1 richieda nuovamente la risorsa prima che P3 termini la sua sezione critica. Se il SO dovesse garantire l'accesso a P1 dopo che P3 abbia finito, e successivamente dovesse garantire alternativamente a P1 e P3 l'accesso alla risorsa, allora P2 potrebbe vedersi indefinitamente negato l'accesso alla risorsa, sebbene non vi sia una situazione di deadlock" (Stallings W.(2015). ''Operating System: internals and design principles''. (8th ed). Pearson)

'''Problema: posso creare sezioni critiche, tramite la programmazione, senza aiuti hardware?'''

ESEMPIO

process p
/*enter_cs*/
A = A + 1
/*exit_cs*/

process q
/*enter_cs*/
A = A - 1
/*exit_cs*/

'''Le 4 proprietà della critical section(CS)'''

SAFETY(1): una operazione all'interno della CS

ESEMPIO
process p
while 1:
/*enter_cs*/
A = A + 1
/*exit_cs*/
... <--- process q deve poter "entrare" qui

LIVENESS(1): no deadlock

LIVENESS(2): no starvation

LIVENESS(3): no useless wait

''Dekker(1st attempt) //KEY: turno''

turn = p //var globale condivisa

process p{
while (turn != p)
;
/*A = A + 1*/
turn = q
...
}

process q{
while(turn != q)
;
/*A = A - 1*/
turn = p
...
}

Non rispetta la proprietà di liveness(3), infatti uno dei due processi può dover attendere a lungo il suo turno eseguendo ciclicamente l'empty statement all'interno
del corpo del while. Questa situazione può verificarsi se l'altro processo fallisce dentro o fuori la sua CS (in questo caso l'attesa è infinita). Inoltre visto che i processi si alternano strettamente nell'utilizzo della loro critical section, il ritmo di esecuzione è dettato dal processo più lento dei due.

''Dekker(2nd attempt) //KEY: flag, ma senza turno''

inp = false

inq = false

process p{
while 1:
while(inq)
;
inp = true
/*A = A + 1*/
inp = false
...
}

process q{
while 1:
while(inp)
;
inq = true
/*A = A - 1*/
inq = false
...
}

In questo caso se uno dei processi fallisce fuori dalla CS (dopo aver settato il flag a false) l'altro processo non viene bloccato. Se invece un processo fallisce nella sua CS oppure dopo aver settato il flag a true allora l'altro processo resta bloccato indefinitamente. Non è garantita inoltre la mutua esclusione in quanto entrambi potrebbero essere al contempo nelle loro rispettive CS, ad esempio:

p valuta la condizione del while e trova inq a false

q valuta la condizione del while e trova inp a false

p assegna true a inp ed entra nella sua CS

q assegna true a inq ed entra nella sua CS

....entrambi sono nella rispettiva CS --> no liveness(1)

''Dekker(3nd attempt) //KEY: come 2nd ma con due istruzioni scambiate di ordine''

process p{
while 1:
inp = true
while(inq)
;
/*A = A + 1*/
inp = false
...
}

process q{
while 1:
inq = true
while(inp)
;
/*A = A - 1*/
inq = false
...
}

Scambiando l'ordine di due istruzioni vi è la mutua esclusione, tuttavia se entrambi i processi assegnano true al loro rispettivo flag, prima di valutare la condizione
del while, entrambi resteranno all'interno del while in attesa che l'altro processo "esca dalla CS" (non vi è mai entrato) --> deadlock

''Dekker(4nd attempt) //KEY: flag + delay''

process p{
while 1:
inp = true
while(inq){
inp = false; < delay >; inp = true;
}
/*A = A + 1*/
inp = false
...
}

process q{
while 1:
inq = true
while(inp){
inq = false; < delay >; inq = true;
}
/*A = A - 1*/
inq = false
...
}

In questo caso il settare il proprio flag a true è indice del desiderio di entrare nella propria CS. Vi è ancora mutua esclusione. Se però dovesse verificarsi una sequenza del tipo:

p imposta flag inp a true

q imposta falg inq a true

p valuta la condizione del while

q valuta la condizione del while

p imposta flag inp a false

q imposta flag inq a false

p imposta flag inp a true

q imposta flag inq a true

allora c'è la possibilità che si ripeta all'infinito (entrambi i processi potrebbero rimanere nel while). Essendo però una condizione che dipende dalla velocità relativa dei due processi, esiseranno delle situazioni nelle quali uno dei due processi potrà entrare, così come vi saranno delle situazioni nelle quali nessun processo avrà accesso alla propria CS --> livelock

'''Dekker...finally //KEY: flag + turni ("cambio delay con turno)'''

needp = false

needq = false

turn = p

process p{
while 1:
needp = true
while (needq) {
needp = false
while(turn == q)
;
needp = true
}
/*A = A + 1*/
needp = false
turn = q
...
}

process q{
while 1:
needq = true
while(needp) {
needq = false;
while(turn == p)
;
needq = true
}
/*A = A - 1*/
needq = false
turn = p
...
}

In questo caso il processo che vuole entrare nella sua CS ne manifesta il bisogno settando need a true. Se entrambi i processi entrano nel corpo del while il tie-break è espletato dal while la cui condizione è un turn che sarà uguale soltanto ad uno dei due processi (in questo caso turn è inizializzata a p), e dunque non si verificherànno situazioni di deadlock o livelock.
*'''Proprietà della sezione critica'''
Mutua esclusione 
Assenza di deadlock 
Assenza di starvation 
Assenza di delay non necessari

*'''La test&set'''
E' un istruzione atomica per impostare il valore di una variabile a 1 (lock) ma ritornare il vecchio valore. Questa istruzione può essere utilizzata per gestire sezioni critiche. 
Il valore ritornato dalla test and set viene comparato a 1, se è uguale si aspetta altrimenti si procede. 
In questo modo il primo processo che cercherà di entrare nella sezione critica ci riuscirà e imposterà il lock a 1, gli altri processi si troveranno il lock a 1 e dovranno aspettare. Quando il primo processo avrà finito ripristinerà il vecchio valore di lock e permetterà a uno degli altri processi di eseguire la test and set e di entrare nella sezione critica.
----
Altri argomenti trattati che non sono stati qui riportati in forma di appunti:
Gestione algoritmica della critical section.
Algoritmo di Dekker.
Gestione architetturale della critical section.

[[User:Renzo|Renzo]] ([[User talk:Renzo|talk]]) 10:35, 17 October 2016 (CEST)

== Lezione del 14 ottobre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7UlJadTRVbzhWRFE 14\10\16]
* Sistemi Operativi per elaboratori multiprocessore SMP/non SMP
* Macchine di von Neumann (e di Harvard).
* Il bus.
* Interrupt e Trap
* Gestione degli interrupt
* Mascheramento degli interrupt
* Interrupt Nidificati
* DMA
* Device a carattere e device a blocchi
* System call come trap.
* La gerarchia delle memorie
* cache

== Lezione del 18 ottobre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7eVlFdWR0cUkxd2M 18/10/16]

Argomenti trattati:
*'''Implementazione in C della Test&Set, degli Algoritmi di Dekker e Peterson.'''
Codice sorgente disponibile [[Dekker,_Peterson_e_Test%26Set_in_C|qui]].
*'''Definizione di Semaforo.'''
Un semaforo è una variabile intera che può essere modificata solo da 2 operazioni atomiche: P(Proberen) e V(Verhogen). 
P aspetta che il valore sia minore o uguale a zero. Quando lo diventa decrementa il valore. 
S incrementa il valore. 
*'''Invariante del Semaforo.'''
Il numero di Proberen deve essere minore o uguale al numero di Verhogen più il valore d'inizializzazione del semaforo. 
In questo modo si può gestire per esempio l'allocazione di risorse. Il semaforo viene inizializzato al numero di risorse e ogni volta che un processo ha bisogno della risorsa esegue un proberen, quindi decrementa il valore se la risorsa è disponibile. Quando un processo rilascia la risorsa esegue un verhogen.
*'''Esempio: implementazione di sezione critica e di semplice sincronizzazione con semafori.'''

== Lezione del 21 ottobre 2016 ==
*'''Make'''
Make è un sistema per la compilazione intelligente dei programmi. 
Permette invece di compilare tutto il programma tutte le volte di compilarne solo una parte, solo quella che è stata modificata.
Per capirne il funzionamento è utile un parallelismo con le ricette di cucina. Si specificano dei target che sono gli obbiettivi della ricetta.Per fare una ricetta servono degli ingredienti e magari quegli ingredienti hanno a loro volta delle ricette. Make allo stesso modo definisce dei target che possono avere come dipendenze altri target. 
Nel installazione del programma il programma ./configure cerca nel sistema se le librerie da cui è dipendente il programma sono presenti. 
*'''Git'''
Git è un sistema di versioning, serve a tener traccia delle modifiche apportante a un progetto nel tempo. E' utile per collaborare a un progetto condiviso. 
Possibilità per ogni membro del repository di lavorare in maniera indipendente e poi aggiornare il progetto comune. 
Ce ne sono stati tanti di sistemi di versioning tipo SVN, Mercurial ma attualmente Git è il più utilizzato. 
Git non serve solo per scrivere programmi ma per esempio anche libri, in modo collaborativo. 
Git è completamente distribuito, non esiste in un repository una copia principale e delle copie secondarie ma ogni copia può essere principale. 
Per iniziare un repository git si utilizza il comando ''git init''. 
Per aggiungere un file al repository si utilizza il comando ''git add''. 
Ma ad ogni singola modifica git non aggiorna automaticamente il repository ma è l'utente che tramite il comando git commit indica che una certa versione del progetto deve essere salvata. 
Il comando ''git log'' serve a visualizzare la storia del repository. 
Il comando ''git diff'' serve a vedere la differenza tra ciò che è nel repository e le modifiche di cui non si è ancora fatto il commit. 
Dopo aver dato il comando add si dice che i file sono 'on stage' prima del commit. 
Il comando ''git checkout'' serve a spostarsi nella storia del repository. 
Il comando ''git clone'' serve a copiare un repository remoto. 
Il comando ''git push'' serve a inviare le modifiche al repository remoto mentre il comando ''git pull'' serve a ricevere le modifiche più aggiornate dal repository remoto. 
Il ''merge'' è il processo in cui uno degli utenti che crea un conflitto deve "a mano" scegliere quali parti dei due commit in conflitto vuole tenere. 
Git è utile per trovare i bug che non erano presenti in versioni precedenti del progetto. Si può tornare alla versione precedente stabile e avanzare nella storia fino a trovare una versione instabile. A questo punto è probabile che l'origine del bug sia nelle modifiche che hanno creato questa versione instabile. 
Github è una piattaforma di repository dove possono essere mantenuti dei progetti gratuitamente se sono con licenza libera. 
In una directory in cui è presente un repository git e sempre la presente la cartella ''.git'' dove il sistema di versioning mantiene il database della storia. 

== Lezione del 25 ottobre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7WjZJMm11cjhuQXc 25/10/16]

Argomenti trattati:
* '''Semafori fair'''
Un semaforo è "fair" quando tende a non sbloccare dallo stato di attesa sempre lo stesso processo ma cerca di distribuire la possibilità di esecuzione a più processi.
* '''Problemi classici della concorrenza risolti con semafori'''
** '''Produttore/consumatore'''
::Due processi: produttore e consumatore. Il produttore genera continuamente dei valori e il consumatore continuamente li legge. Il consumatore deve leggere i valori nello stesso ordine in cui il produttore li genera. 
::Un meccanismo di sincronizzazione e richiesto perchè sorgono immediatamente due problemi:
::* Produttore troppo veloce: il consumatore non fa in tempo a consumare il valore e c'è la possibilità che i valori non ancora letti vengano sovrascritti.
::* Consumatore troppo veloce: possibilità che il consumatore legga un valore che ha già letto perchè il produttore non ha fatto in tempo a produrne uno nuovo.
::Per risolvere il problema utilizziamo due semafori: empty e full. 
::Il produttore aspetta che il segnale del semaforo empty (Proberen), scrive il valore e dà segnale sul semaforo full (Verhogen). 
::Il consumatore aspetta il segnale del semaforo full (Proberen), legge il valore e dà segnale sul semaforo empty (Verhogen). 
:* '''Buffer-limitato'''
::Simile al problema produttore/consumatore ma qui lo scambio avviene tramite un buffer limitato. 
::In questo modo nel caso di rallentamento temporaneo del consumer il producer non deve aspettare ma può produrre più unità e viceversa nel caso di rallentamento del producer, se il buffer ha più di un elemento, il consumer può utilizzare il tempo in attesa del producer per consumare più dati. 
::Nel caso il buffer sia completamente pieno/vuoto rimangono comunque i problemi di sincronizzazione tipici del problema: il producer non deve sovrascrivere dei valori che il consumer non ha ancora letto e il consumer non deve leggere più volte lo stesso valore se il producer non è stato abbastanza veloce da cambiarlo. 
::Come soluzione al problema si può utilizzare un coda circolare. Il produttore esegue una enqueue e il consumatore una dequeue. 
::Il problema può essere generalizzato facilmente a produttori/consumatori multipli ma in questo caso dobbiamo creare un semaforo per rendere atomiche la enqueue e la dequeue altrimenti incorriamo in una race condition nel accesso alla coda.

== Lezione del 28 ottobre 2016 ==

'''Implementazione dei semafori''' 
Un processo che esegue una Proberen in teoria dovrebbe aspettare continuando a controllare se può entrare nella sezione critica. Questo meccanismo si chiama "busy waiting" e consuma molte istruzioni della CPU. 
Il busy waiting è diverso dal polling in quando il polling prevede di eseguire altre azioni mentre si aspetta tra un tentativo e l'altro. 
Di solito si utilizza il busy waiting solo quando il tempo di lock di un processo è molto breve. Questo perchè anche se esoso di risorse del processore il busy waiting non comporta un context switch, cioè salvare tutto lo stato del processo in memoria, e quindi permette di risparmiare memoria.
Se invece il tempo di lock è più lungo allora è preferibile utilizzare un context-switch dove il processo si blocca da solo e chiama un processo di blocking che lo mette in una coda di attesa associata al semaforo che sta aspettando. Il controllo passa poi allo scheduler della CPU che seleziona un altro processo da eseguire.
Le primitive suspend and wakeup indicano rispettivamente lo spostamento di un processo nella/dalla coda dei processi ready.
* nei kernel monoprocessore
: Implementazione dei semafori tramite mutex che possono essere a loro volta implementate con un sistema di mascheramento degli interrupt.
* nei kernel multiprocessore
: Utilizzo di soluzioni hardware come test and set. Sono soluzioni che utilizzano il busy waiting ma in questo caso solo per rendere atomico le operazioni del semaforo, che sono poche istruzioni.
Certe implementazioni dei semafori potrebbero permettere di far andare il valore in negativo. Questo serve per misurare il numero dei processi in attesa di quel semaforo. 
'''Il problema della cena dei filosofi''': 
5 filosofi passano la loro vita pensando e mangiando. Condividono un tavolo circolare con 5 sedie e ogni sedia appartiene a un solo filosofo. Alla sinistra e alla destra di ogni piatto c'è una bacchetta per un totale di 5 bacchette. La bacchetta destra che un filosofo usa per mangiare viene quindi utilizzata come bacchetta sinistra dal filosofo alla sua destra e simmetricamente è uguale per il filosofo che siede a sinistra. 
Ogni tanto un filosofo smette di pensare e cerca di prendere le rispettive bacchette, se ci riesce può mangiare e poi rilasciare le bacchette. 
Questo problema è un modello di problema ad accesso a ''insiemi'' di risorse. Mentre nel produttore/consumatore e buffer limitato gli attori in gioco avevano la necessità di avere l'accesso esclusivo a una sola risorsa in questo problema è richiesto l'accesso a insiemi di risorse (le bacchette) le cui parti possono essere desiderate da altri richiedenti.
* soluzione con contesa sulle posate e casi di deadlock
:Poniamo un semaforo per ogni bacchetta. Può succedere però, se nel implementazione i filosofi "prendono in mano" prima la bacchetta destra e poi quella sinistra, che tutti prendono in mano contemporaneamente la bacchetta destra e rimangono in un'attesa infinita della bacchetta sinistra che non gli verrà mai rilasciata perché anche il rispettivo filosofo alla propria sinistra è in attesa. Questo è un caso di deadlock. 
:Una soluzione può essere quella di imporre che un filosofo sia "mancino" cioè prenda prima la bacchetta a sinistra e poi la destra. 
* soluzione con acquisizione atomica di entrambe le posate, casi di starvation
:Un'altra soluzione è quella di rendere atomico l'acquisizione di entrambe le posate. 
:Può succede che 4 filosofi compiano una "congiura", cioè siano d'accordo a non lasciar risorse a un quinto filosofo. Questo è un caso di starvation e non è irreale in quando i 4 filosofi potrebbero essere processi malevoli che siano stati programmati di proposito per questo.
'''System Call''':
* POSIX.
:Il POSIX è uno standard (IEEE 1003) che definisce le signature delle system call. Un sistema operativo deve rispettare il POSIX per essere definito "Unix-like". 
:Di solito i parametri delle system call sono pensati per essere contenuti in un registro. Quasi sempre le system call ritornano un intero: 0 se la procedura è stata eseguita correttamente, -1 se c'è un errore. Quando una system call ritorna -1 la variabile "globale" errno (error number) contiene il codice di errore. La variabile errno non è realmente globale perché ne esiste una per ogni processo. 
:Unix è un sistema operativo file-system centrico quindi quando facciamo input/output anche da periferiche come stampanti e lettori CD usiamo le system call per la scrittura/lettura dei file. 
:Un catalogo delle system call principali può essere trovato [[Il ''catalogo'' delle System Call | qui]].
* fork/exec
:fork e exec sono system call importanti e servono per creare un nuovo processo: 
:fork: genera un processo clone di quello che ha chiamato fork. 
:exec: "cambia" il codice eseguito dal processo corrente. 
:Quindi per "aprire un nuovo programma" si utilizza una fork seguita da un exec.

== Lezione del 4 novembre 2016 ==
Audio Lezione: [https://drive.google.com/open?id=0B8G3NNuJ7MA7blhMT0tSNDRGSUU 4/11/16]

* '''Problema della Cena dei filosofi'''. Soluzione con acquisizione atomica delle bacchette (con starvation)
* '''Tecnica del passaggio del testimone''' (Passing the Baton).

: Non uscire dalla mutua esclusione se c'è qualcun altro che vuole entrarci e semplicemente fare in modo che lui l'acquisisca. La mutua esclusione termina solo se non c'è nessuno che più la richiede.

ESEMPIO IMPLEMENAZIONE BATON
<syntaxhighlight lang=C>
void baton(int i) {
int j;
for (j=1; j<5; j++) {
if(philo_status[(i+j)%5] == 'W' && philo_status[(i+j+1)%5] != 'E' && philo_status[(i+j+4)%5] != 'E') {
semaphore_V(philowait[(i+j)%5]);
return;
}
}
semaphore_V(mutex);
}
</syntaxhighlight>
* '''Cena dei filosofi, acquisizione atomica delle bacchette con passaggio del testimone'''.
* '''Implementazione della congiura dei filosofi'''

* '''Le system call di gestione file (open, read, write, close, lseek)'''
Quando lavoriamo con dei file dobbiamo sempre specificare se vogliamo solo leggerli oppure anche scrivere, magari in append mode. Ci sono quindi varie modalità con cui possiamo interagire con i file. 
Un utente potrebbe essere autorizzato a gestire il file in certe modalità oppure no. 
Il descrittore di un file è un intero. 
Le system call, a differenza delle chiamate di funzioni di libreria, non sono bufferizzate.

ESEMPIO

Se si decommenta printf stampa 2 volte hello world perchè la stringa resta nel buffer.

Se si decommenta write stampa 1 volta hello world.

Per vedere le chiamate di sistema effettuate in fase di esecuzione, compilare il codice sorgente e poi utilizzare strace -f "eseguibile".
<syntaxhighlight lang=C>
#include<stdio.h>
#include<unistd.h>

int main(int argc, char* argv[]){
//printf("hello world"); //if you ends the strings with \n is like to "fflushing" the buffer
//write(1, "hello world", 11); // 1 and 11 are file descriptors
switch(fork()) {
case 0: //child
break;
default: //parent
wait(NULL);
break;
case -1: //error
break;
}
printf("\n");
return 0;
}
</syntaxhighlight>

Copia il file passato come primo argomento (argv[1]) nel file passato come secondo argomento (argv[2]), se quest'ultimo non esiste, allora lo crea.
<syntaxhighlight lang=C>
#include<stdio.h>
#define BUFSIZE 2048
char buffer[BUFSIZE];
int main(int argc, char *argv[]){
int fdin = open(argv[1], O_RDONLY);
int fdout = open(argv[2], O_WRONLY | O_CREAT | O_TRUNC, 0666); //0666 is the umask used to modify the permissions of new files

int n;
while((n = read(fdin, buffer, BUFSIZE)) > 0)
write(fdout, buffer, n);

close(fdin);
close(fdout);
return 0;
}
</syntaxhighlight>

'''umask''' 
Con la open possiamo usare dei permessi al massimo per quelli garantiti dal umask. 
Un numero composto da quattro cifre ottali. Controlla la maschera di creazione dei file. I bit di permesso contenuti nella maschera NON vengono settati nel nuovo file creato. Corrisponde all'opereazione:

R:(D &(~M))

Può essere vista come una sottrazione, i bit accesi nella umask vengono spenti nel file creato.

e.g. se i permessi di default corrispondono a 0666(D) e la maschera corrisponde a 0022(M), R è uguale a 0666-0022 = 0644. Infatti

0022 = |000|000|010|010|
~0022 = |111|111|101|101|(7755)
0666 = |000|110|110|110|
~0022 & 0666 = |000|110|100|100|(0644)

Tabella significato cifre umask

OTTALE BINARIO SIGNIFICATO
0 000 Nessun permesso
1 001 Solo esecuzione
2 010 Solo scrittura
3 011 Scrittura ed esecuzione
4 100 Solo lettura
5 101 Lettura ed esecuzione
6 110 Lettura e scrittura
7 111 Lettura, scrittura ed esecuzione

I permessi sono rappresentati in simboli come segue:

r: read
w: write
x: execute

'''umask - S''' da shell per visualizzare la umask attuale con rappresentazione simbolica

'''ls -l "nomefile"''' da shell per visualizzare i permessi del file in notazione simbolica: '-' seguito da 3 triple che indicano i permessi di accesso per '''ugo''', ovvero, rispettivamente, per user, per group, per other.

ESEMPIO
-rw-r--r--

* '''File aperti durante fork/exec'''https://www.kernel.org/

I file aperti vengono ereditati dai processi figli.
Processo padre e processo figlio condividono lo stesso offset nei file comuni. In questo modo si evita di sovrascriversi a vicenda. Ogni volta che il padre o il figlio scrivono sul file aggiornano l'offset comune.In questo modo se l'altro processo vuole anche lui scrivere in quel file partirà dal offset aggiornato e non sovrascriverà i dati scritti dal altro processo. 

* '''La system call dup e la ridirezione'''
E' possibile fare in modo che più file descriptor siano associati a un unico file (per la precisione a un unica file table, che serve per gestire un file). 
La system call dup permette di fare ciò. Ritorna un nuovo file descriptor che punta a una file table già esistente. 
Possiamo quindi "ridirezionare" l'output o l'input di un processo figlio modificando i file descriptor prima di creare il processo figlio. Per esempio possiamo modificare un file descriptor che puntava a un normale file in modo che punti a un file di standard output e quindi anche se al processo figlio sembrerà di scrivere in un normale file starà scrivendo nel terminale.

ESEMPIO

<syntaxhighlight lang=C>
#include<sys/types.h>
#include<sys/stat.h>
#include<fcntl.h>
#include<stdio.h>
#include<unistd.h>

int main(int argc, char * argv[]){
int fdout;
if(argc > 1);
fdout = open (argv[1], O_WRONLY | O_CREAT | O_TRUNC, 0666);
switch(fork()) {
case 0: //child
dup2(fdout, 1); // duplica descrittore file, posso ridirezionare l'output. E' come fare '>' dalla shell
execlp(”ls”, “-l”, 0);
close(fdout);
break;
default: // parent
wait(NULL);
break;
case -1: // error
break;
}
printf(“\n”);
return 0;
}
</syntaxhighlight>

== Lezione del 8 novembre 2016 ==
'''Codice per la congiura dei filosofi'''
<syntaxhighlight lang=C>
#include <stdio.h>
#include <stdint.h>
#include <pthread.h>
#include "semaphore.h"

semaphore philowait[5];
semaphore mutex;
semaphore cospsem;
char philo_status[]="TTTTT";

void baton(int i){
int j = 0;
//iterate through remaining philosophers
for(j = 1; j < 5;j++){
//if there's any waiting philosopher, and no other philosophers(on his left and right side) are eating
if(philo_status[(i+j)%5]=='W' && philo_status[(i+j+1)%5]!= 'E' && philo_status[(i+j+4)%5]!='E'){
semaphore_V(philowait[(i+j)%5]);
return;
}
}
semaphore_V(mutex);
}

void ok2eat(int i){
semaphore_P(mutex);
philo_status[i]='W';
if(philo_status[(i+1)%5] == 'E' || philo_status[(i+4)%5] == 'E'){
semaphore_V(mutex);
semaphore_P(philowait[i]); //wait for baton
}
philo_status[i] = 'E';
printf("philo eating: %d |%s|\n",i,philo_status);
baton(i);
}

void ok2think(int i){
semaphore_P(mutex);
philo_status[i] = 'T';
printf("philo thinking: %d |%s|\n",i,philo_status);
baton(i);
}

void conspiracy_in(){
static int first_time = 1; //this variable's value is preserved between calls to this function
semaphore_P(mutex);
if(first_time){
//first conspirator entering here will act like nothing happened
first_time = 0;
}
else{
//conspire
semaphore_V(cospsem);
}
semaphore_V(mutex);
}

void conspiracy_out(){
semaphore_P(cospsem);
}

void *philo(void *arg) {
int i = (uintptr_t)arg;
while (1) {
//thinking/still thinking
usleep(random() % 200000);
ok2eat(i);
//eating

//conspirators need to be synchronized to conspire
if(i==1 || i==3) conspiracy_in();
usleep(random() % 200000);
if(i==1 || i==3) conspiracy_out();
ok2think(i);
//thinking again
}
}

int main(int argc, char *argv[]) {
int i;
pthread_t philo_t[5];
srandom(time(NULL));
mutex = semaphore_create(1);
cospsem = semaphore_create(0);
for (i=0; i<5; i++)
philowait[i]=semaphore_create(0);
for (i=0; i<5; i++)
pthread_create(&philo_t[i], NULL, philo, (void *)(uintptr_t) i);
for (i=0; i<5; i++)
pthread_join(philo_t[i], NULL);
}
</syntaxhighlight>

* '''Problema dei lettori e scrittori'''
:Spesso quando gestiamo la concorrenza all’accesso a strutture dati separiamo i ruoli di solo lettori con anche quello di scrittori (che per fare ciò possono dover anche leggere).
:Mentre che per i lettori non c’è un limite a quanti contemporaneamente possono avere accesso alle informazioni, gli scrittori devono avere accesso esclusivo alla struttura dati.
:Questo perché incorriamo in una race-condition solo quando modifichiamo la struttura dati.
:Dare precedenza di accesso a una categoria o all’altra porta starvation nella categoria con meno priorità.
:Una soluzione che abbiamo dato è quella di dare esclusività ai ruoli a turno:
:dopo che uno scrittore ha finito di scrivere garantisce l’accesso prima a tutti i lettori in attesa e se non sono presenti agli scrittori in attesa. Per i lettori è il contrario: dopo che l’ultimo lettore ha finito di leggere garantisce l’accesso a uno dei possibili scrittori in attesa e se non ce ne sono ai lettori.
:La soluzione in C al problema lettori e scrittori può essere trovata [[Zibaldone|qui]].
* '''Semafori Binari(Introduzione)'''
: Un semaforo binario è un semaforo ordinario che rispetta la seguente invariante: '''nP<=nV+Init<=nP+1''', ovvero è un semaforo che può assumere solo valori 0 o 1.
: Si può dimostrare che i semafori ordinari sono espressivi tanto quanto quelli binari(e viceversa) fornendo una implementazione di semafori binari tramite i semafori ordinari e viceversa una implementazione di semafori ordinari tramite semafori binari. (l'invariante dei semafori binari si può anche scrivere '''0 <= nV + Init - nP <= 1''' dove '''nV + Init - nP''' rappresenta proprio il valore del semaforo).

== Lezione del 11 novembre 2016 ==
* '''Valore di ritorno di un processo'''
:Un processo ritorna un valore che è un numero intero. 
:Questo può essere deciso come valore di ritorno del main, oppure con la funzione ''exit''.
:La system call wait aspetta che lo stato di un processo figlio cambi e quando cambia scrive il nuovo in una variabile. 
:Quando un programma termina il suo valore di ritorno viene salvato nel descrittore del processo. Se il padre non esegue la wait il descrittore del processo figlio non verrà mai eliminato e il processo figlio rimarrà uno "zombie".
:Un esempio del uso si queste system call si può trovare [[2016-17_Programmi_C#Print_child_exit_status|qui]].
* '''Pipe'''
:La system call pipe crea un canale monodirezionale che può essere usato per la comunicazione tra processi. Dimostrazione del uso di pipe si può trovare [[2016-17_Programmi_C#Demonstration_of_the_use_of_pipe_system_call|qui]].
* '''Lo zoo delle exec'''
<syntaxhighlight lang='C'>
int execl(const char *path, const char *arg, ...);
int execlp(const char *file, const char *arg, ...);
int execle(const char *path, const char *arg, ..., char * const envp[]);
int execv(const char *path, char *const argv[]);
int execvp(const char *file, char *const argv[]);
int execvpe(const char *file, char *const argv[],char *const envp[]);
</syntaxhighlight>
Spiegazione dei postfissi:
* l = elenco dei parametri passato tramite parametri a cardinalità variabile (variadic function)
* v = elenco dei parametri passato come array
* p = bisogna specificare il path completo dell'eseguibile
* e = bisogna specificare anche l'enviroment con cui verrà eseguito il programma. L'enviroment è una serie di variabili globali, tra cui il path. Il path è l'elenco dei percorsi dei programmi più usati.
Tutte queste funzioni alla fine sono solo delle interfacce per execve.
* '''Programmazione ad eventi'''
:E' un paradigma di programmazione dove il flusso del programma è determinato dal avverarsi di eventi. Il programmatore specifica il codice (Handlers) che deve essere eseguito al verificarsi di un certo evento. 
:System call che sono utili per far questo sono select,pselect,poll,ppoll,epoll.

== Lezione del 15 novembre 2016 ==
* '''Differenza tra select,poll,pselect,ppoll e epoll'''
:La poll a differenza della select richiede un array di strutture pollfd invece che una bitmask. Permette di specificare precisi eventi per cui stare in ascolto. 
:Le versioni con prefisso "p" implementano anche la gestione dei segnali. 
:L'epoll è linux only. E' moderna (2002) e fornisce un file dove leggere direttamente quali file descriptor sono stati modificati in modo da non dover scorrere tutta la lista.
* '''Dimostrazione della equivalenza di potere espressivo fra semafori e semafori binari.'''
:I semafori implementati per dimostrare l'equivalenza possono essere trovati a [[Esperimenti_con_semafori_e_monitor_in_C | questa pagina]].
* '''Definizione di Monitor.'''
Un monitor è un costrutto ad alto livello per la sincronizzazione pensato ispirandosi alla programmazione ad oggetti. 
E' una classe che incapsula la risorsa condivisa, la rende privata e permette di accedere a questa solo tramite metodi. Questi metodi implementano i meccanismi di sincronizzazione. 
Uno solo processo può essere al interno del monitor e avere accesso ai dati protetti da mutua esclusione. 
E' presente una coda di attesa per l'accesso al monitor. 
Definiamo inoltre delle variabili ''condition''. 
Gli unici metodi che possono essere chiamati su una condition sono wait e signal. Ogni condition ha una propria coda di attesa 
L'operazione wait sospende il chiamante e lo sposta nella coda di attesa della condition.
L'operazione signal risveglia un processo in attesa. Se non c'è nessun processo in attesa all'interno del monitor la signal fa entrare un eventuale processo in attesa di entrare nel monitor. Il chiamante di signal dopo aver risvegliato l'altro possibile processo deve mettersi in attesa per evitare che ci siano due processi in concorrenza al interno del monitor, ma invece di andare nella coda di attesa della condition viene messo in un ''urgent stack'' che ha più priorità rispetto alla coda esterna dei processi in attesa di entrare nel monitor. 
Ricapitolando le strutture dati per un monitor sono una coda esterna per l'accesso al monitor, una coda interna (non accessibile da fuori ma non dentro la mutua esclusione) per ogni variabile condizionale e l'urgent stack. 
* '''Implementazione dei Semafori tramite monitor.'''

== Lezione del 18 novembre 2016 ==
* '''File speciali a blocchi o a caratteri'''
: In Unix molte cose sono rappresentate come file. Per esempio i device come i terminali e le partizioni del disco sono file. Si chiamano ''file speciali'' ma non sono tanto differenti dai file comuni. Utilizzano anche gli stessi sistemi di protezione all'accesso. Si dividono i due categori:
:* File speciali a blocchi: utilizzati maggiormente dai sistemi di storage tipo hard-disk e CD-ROMs. Se per esempio il blocco è di 1024 bytes allora possiamo scrivere e leggere con tale granularità, cioè non potremo mai scrivere soltato 500 bytes ma dovremo scrivere, appunto a "blocchi".
:* File speciali a caratteri: utilizzati maggiormente per dispositivi di input-output tipo mouse,tastiera,terminali ecc.. permettono di lavorare con una granularità di 1 byte ma hanno un accesso sequenziale invece che diretto come i file a blocchi.
:Inoltre nei file speciali l'ampiezza è sostituita da 2 numeri, uno che indica il driver del dispositivo e l'altro le possibili parti del dispositivo, per esempio le partizioni.
* '''System call ioctl'''
: Ioctl serve per controllare dei device. Per esempio permette di fermare la testina di lettura del disco oppure far partire il motore del lettore CD. E' necessaria in quando si è voluto uniformare la lettura e scrittura di stream per tutti i device tramite le system call read/write ma chiaramente ogni dispositivo ha anche le sue diverse necessità e queste vengono soddisfatte da ioctl.
* '''Syscall'''
: Syscall è una funzione di libreria C che serve a chiamare system calls che non hanno una loro interfaccia per il linguaggi C. Per esempio getdents.
* '''System call e funzioni di libreria per directory'''
:Le directories sono sempre file ma si può fare l'accesso solo in lettura, per esempio per ottenere la lista di tutti i file e directory all'interno di quella directory. 
:getdents legge un file directory ed è la system call principale, tutte le funzioni di libreria C tipo opendir,readdir,readdir_r(per multithread) chiamano getdents. 
:Tutte queste funzioni lavorano con una struct dirent che rappresenta una directory entry. 
:Si può usare anche scandir che è reetrant (nessun problema di race condition) e invece di leggere un elemento della directory per volta ritorna direttamente un array di tutti gli element allocato dinamicamente (occorre ricordarsi di deallocare con free tutti gli elementi e l'array stesso).

== Lezione del 22 novembre 2016 ==

Problema dei filosofi a cena risolto con i monitor. Soluzione con le condizioni associate alle "bacchette" e con le condizioni associate ai filosofi.
discussione dei problemi di deadlock e starvation nell'implementazione tramite monitor.

Problema dei lettori e scrittori tramite monitor. Soluzione con privilegio ai lettori, agli scrittori e modifiche necessarie per la soluzione priva di starvation.

== Lezione del 25 novembre 2016 ==
[[Coding Contest]]

== Lezione del 29 novembre 2016 ==
* '''Implementazione dei monitor tramite semafori'''
:Un soluzione simile a quella vista a lezione può essere trovata [[Esperimenti_con_semafori_e_monitor_in_C#Monitor implementati con semafori | qui]].
* '''Introduzione al message passing'''
:E' un altro modo per fare programmazione concorrente alternativo alla memoria condivisa che abbiamo visto fin ora.
:Se i programmi non condividono memoria ma devono sincronizzarsi per lavorare assieme hanno bisogno di scambiarsi messaggi.
:Per l'indirizzamento serve un sistema di naming, come il pid dei processi.
:Due primitive: send e receive. Nella receive come indirizzo da chi ricevere si può mettere una wildcard in modo da riceve da tutti.
:Nella send invece occorre indicare l'identificativo del destinatario (se si ammettesse di poter inserire una wildcard si spedirebbero messaggi in broadcast/multicast. E' una problematica più complessa che viene trattata nei corsi di sistemi distribuiti).
:Lo scambio di messaggi può essere:
:* Sincrono: send bloccante e receive bloccante, senza memoria di supporto.
:* Asincrono: send non bloccante e receive bloccante, con memoria di supporto. I messaggi spediti rimangono in una coda (di ampiezza massima illimitata nel modello).
:* Completamente asincrono: send non bloccante e receive non bloccante. Poco utilizzato, il destinatario deve fare un polling per controllare se il messaggio è arrivato o no.
:Per dimostrare la stessa espressività dei metodi dobbiamo sempre creare delle librerie e non dobbiamo aggiungere nessun processo.
:La metodologia asincrona è espressiva almeno quanto quella sincrona mentre non è vero il contrario.
:Per creare un metodo sincrono con chiamate asincrone basta bloccare il programma finché non si riceve un acknowledgement.
:Invece per creare un metodo asincrono con chiamate sincrone bisogna aggiungere un processo e quindi questo dimostra che non sono equivalentemente espressive.
* '''Soluzioni di esercizi d'esame'''
** Problema della lavatrice
** Problema del ponte a senso unico

== Lezione del 2 dicembre 2016 ==
* '''Implementazione della libreria per message passing'''
:I sorgenti della implementazione possono essere trovati [[Esperimenti con message passing in C|qui]]
* '''I segnali'''
:I segnali sono un metodo di comunicazione tra processi utilizzato in UNIX.
:Ogni segnale è rappresentato da un numero. Per esempio "segmentation fault" è il numero 11.
:La system call kill() serve per inviare un segnale. signal() serve per definire l'handler, una funzione che viene eseguita quando il processo riceve uno specifico segnale.
:Ogni segnale ha il suo handler di default e tramite signal() noi sovrascriviamo il default handler.
* '''Permesso setuid'''
:Permette a dei programmi di eseguire operazioni che hanno bisogno dei permessi di root. L'attributo setUserId attivato vuol dire che il programma verrà eseguito con i privilegi del possessore del file piuttosto di quelli di chi lo esegue.
* '''Proposta di soluzione esercizio 4 del [[Coding Contest 25 novembre 2016]]'''

== Lezione del 6 dicembre 2016 ==

* Implementazione di un servizio di Message Passing Asincrono dato uno sincrono (con processo server).
* Implementazione di un servizio di Message Passing completamente asincrono dato uno sincrono.
* Analisi del potere espressivo dei servizi di message passing.

* kernel monolitici e microkernel
* macchine virtuali a livello di processo e a livello di sistema

I sorgenti degli esperimenti con il message passing sono in [http://www.cs.unibo.it/~renzo/so/tools/mp.extra.tgz questo file].

== Lezione del 9 dicembre 2016 ==

* Il problema della Cena dei filosofi con il message passing (asincrono)

* Buffer Limitato con message passing (asincrono).

== Lezione del 13 dicembre 2016 ==

La lezione TACE per malattia (influenza) del docente.

== Lezione del 16 dicembre 2016 ==
*'''Specifiche del progetto fase uno'''
Il documento delle specifiche può essere trovato [http://www.cs.unibo.it/~renzo/so/mikaboo/phase1.pdf qui].
:*List.h
:*Lista dei processi
:*Coda dei thread
:*Code dei messaggi
*'''Autotools'''
:Insieme di strumenti per la generazione automatica di Makefiles. 
:comando ''autoreconf'' per generale il file ''configure'' 
:''./configure'' per generare makefile.

== Lezione del 21 febbraio 2017 ==
'''Argomenti trattati:'''
* '''Visione a strati di un elaboratore'''
:Gli strati sono livelli di astrazione. Ogni strato deve "parlare" il linguaggio del livello sottostante e deve fornire un proprio linguaggio ai livelli superiori.
:Per esempio il sistema operativo parla l'ISA del livello hardware e fornisce alle applicazioni le system call. Il sistema operativo maschera il livello hardware in quanto fornisce la possibilità alle applicazioni di utilizzare istruzioni ISA ma non tutte, per ragioni di sicurezza.
* '''Componenti fondamentali di un sistema operativo'''
:A sua volta il sistema operativo può essere visto come un insieme di strati. Esistono sistemi operativi a singolo strato (come MS-DOS) e più strati (layered).
:Le parti principali in cui possiamo suddividere un sistema operativo sono:
:*Lo scheduler
:*Il memory manager
:*Il file system
:*L'I/O manager
:*Il networking manager
:Di questa lista, gli elementi assolutamente fondamentali per considera un programma un sistema operativo sono lo scheduler e una parte essenziale del memory e I/O manager.
:Il networking e file manager si appoggiano al I/O manager per svolgere i loro compiti.
*'''Bootstrap'''
:Letteralmente "mettersi in piedi tirandosi dai lacci degli stivali", nel senso di attivarsi senza aiuto esterno. All'accensione il computer legge da una ROM le prime istruzioni necessarie. Viene sempre letto dai primi settori della memoria di massa il bootloader. :Il bootloader (per esempio GRUB) conosce già molti filesystem, ma non abbastanza. Il bootloader carica un file system temporaneo apposito chiamato initrd per caricare i moduli necessari al kernel.
*'''Come rappresentiamo i processi'''
:Dobbiamo sia tener conto a che punto siamo arrivati nell'esecuzione del processo sia tener conto delle risorse di cui il processo è detentore.
:Utilizziamo la struttura ''Process Control Block'' (task_struct in linux) per i processi e "Thread Control Block" (task_struct in linux) per i thread.
:Process control block:
:*PID (Process ID)
:*PPID (Parent Process ID) per poter creare una gerarchia di processi
:*punti di accesso alla memoria (codice,dati,tabella di rilocazione,paginazione)
:*lista dei thread
:*owner (se il sistema è multiuser)
:*Risorse del processo
:*Coda dei messaggi per IPC (Inter-Process Communication)
:*accounting (tempo di esecuzione sia in modalità kernel sia in modalità user)
:*valore di ritorno del processo
:Thread control block:
:*TID (Thread ID)
:*stato del processore
:*call stack
:*ready/running/waiting
*'''Avvicendamento dei processi'''
:Definizione di avvicendamento: ''Successione prevista o regolata nel tempo, alternanza.''
:I context switch avvengono a seguito di trap/interrupt.
:Il ciclo di vita di un processo passa tra gli stati ''ready, running, waiting'' e infine ''term''.
:Lo scheduling (processo decisionale) può venire applicato nelle seguenti 4 situazioni:
:# Quando un processo passa dallo stato di running a quello di waiting
:# Quando un processo passa dallo stato di running a quello di ready
:# Quando un processo passa dallo stato di waiting a quello di ready
:# Quando un processo passa dallo stato di running a quello di term
:Se lo scheduling avviene solo nella situazione 1 e 4 allora si utilizza un metodo non preemptive. Dal momento che la CPU è allocata a un processo questo la detiene finchè non termina o entra di sua spontanea volontà in stato di waiting. La CPU non può decidere di far aspettare un processo spostandolo temporaneamente nella coda dei processi ready. Questo sistema era utilizzato da vecchi sistemi operativi come Windows 3.x e dalle versione di Mac OS prima della versione X.
:Nel preemptive scheduling invece la CPU può decidere di sospendere un processo, questo può creare race condition ma anche un sistema più equo di distribuzione delle risorse. Le race condition vengono risolte con i metodi che abbiamo visto nel primo semestre.
'

== Lezione del 23 febbraio 2017 ==

'''System call'''

Abbiamo analizzato le system call che erano già presenti nella [http://man.cat-v.org/unix-6th/2/ versione 6 di Unix] (1975). 
Le abbiamo poi confrontate con quelle attuali del [[Il_%27%27catalogo%27%27_delle_System_Call]].

'''Shell Scripting'''

Gli script vengono utilizzati per lanciare un demone, guardare i processi, etc.
Anche l'amministrazione di sistema avviene tramite scripting. Ad esempio, dopo il boot, il processo init avvia le funzionalità di sistema tramite script.

Unix unifica l'idea di script con quella di shell.
La shell è un processo che interagisce con l'utente. In Unix la novità introdotta è rappresentata dalla presenza di un linguaggio che riguarda i comandi, utile per scrivere gli script per la shell.

Come indichiamo quale shell usare? Scrivendo nella prima riga #! seguito dal path e dal nome della shell. Il kernel prende ciò che è scritto nella prima riga e lo esegue per interpretare lo script.
Nell'esempio sottostante Script è un commento perchè è preceduto da #.

ESEMPIO

#!/bin/bash
#Script

echo "Hello World!"

Per scrivere script abbiamo bisogno di variabili. Nelle shell queste possono essere di 2 tipi:

- Locali: viste solo dalla shell, non perturbano comportamento dei processi.

- D'ambiente: recepita dai comandi come ambiente.

'''ASSEGNAMENTO E VARIABILI'''

ESEMPIO 1

a=2 /* Non devono esserci spazi!!! a = 2 doesn't work */
echo $a /* Stampa 2 */
echo ${a}a /* Stampa 2a */

ESEMPIO 2 - Nuova shell

bash /* Apro nuova shell */
echo $a /* Stamperà una riga vuota perchè la var. a non è locale della nuova shell */
exit /* chiudo nuova shell */

ESEMPIO 3 - Esportare variabile locale

export a /* La var. a diventa variabile d'ambiente */
bash
echo $a /* Ora possiamo chiamare la var. a perchè è diventata d'ambiente */

ESEMPIO 4 - csh

csh in molti casi dovrebbe già essere installato di default.
Se non è così è possibile installarlo eseguendo

sudo apt-get install csh

csh /* Apro cshell, noterete il simbolo di percentuale % a inizio riga di comando */
set a=42 /* assegnamento */
csh /* apro nuova shell */
echo $a /* non possiamo chiamare a(42) perchè locale alla prima shell, viene chiamata a d'ambiente se presente */
exit
setenv a 42 /* Per creare una variabile d'ambiente, da notare la mancanza di = */
csh
echo $a

'''ARGOMENTI'''

Negli script possiamo avere degli argomenti.
Vengono visti come $1, ..., $9, ${10}, etc.
$* indica tutti gli argomenti

ESEMPIO 1
#!/bin/bash
echo $* /* Richiama tutti gli argomenti */
echo $1 $2 /* Richiama solo i primi due argomenti */
shift /* Sposta la riga di comando degli argomenti di una posizione verso sx */
echo $*

Una volta salvato il file con estensione .sh, eseguire da terminale:
chmod +x nomefile.sh
./nomefile.sh arg1 arg2 ...

Se passiamo come argomenti: uno due tre quattro,
l'output sarà:
uno due tre quattro
uno due
due tre quattro

A volte dobbiamo proteggere dei caratteri. Alcuni di essi possono essere delle wildcard. Ci sono 3 modi per proteggerli:
\*
'*'
"*"

Analizziamone le differenze tramite un esempio.

ESEMPIO 1

echo \* // OUTPUT: *
echo '*$a' // OUTPUT: *$a
echo "*$a" // OUTPUT: *2

Nel primo caso l'escape vale solo per *. Nel secondo caso vale per tutta la stringa. Nel terzo caso vale per * e richiama la variabile.

ESEMPIO 2
echo ab // OUTPUT: ab
echo "ab" //OUTPUT: ab

echo a b //OUTPUT: ab <-- non rileva gli spazi
echo "a b" //OUTPUT: a b

== Lezione del 28 febbraio 2017 ==
'''Argomenti trattati''':
* '''Ciclo di vita di un kernel'''
: Dopo l'inizializzazione (Creazione di code, rilevazione di device, ecc..) si crea a "mano" il primo processo.
: L'esecuzione dello scheduler si alterna a quella dei processi. Quando un processo utente viene eseguito il kernel non ha più il controllo del flusso e gli viene restituito solo quando avviene un interrupt/trap.
* '''Parametri di valutazione di un algoritmo di scheduling'''
** % Utilizzo CPU: Bisogna cercare di tener utilizzata il processore il più possibile riducendo i momenti di inutilizzo (idle).
** Produttività (Throughput) Numero di processi completati per unità di tempo
** Tempo totale (turnaround time) Tempo totale impiegato dall'esecuzione del processo al completamente. Tiene conto del tempo speso in attesa oltre al tempo in esecuzione.
** Tempo di risposta: Tempo prima che un primo output venga generato dal momento in cui il processo viene eseguito. In un sistema interattivo è importante per non dare all'utente l'idea di malfunzionamento.
** Tempo di attesa. Non aspettando l'I/O ma bensì tempo speso nella ready queue.
* '''Processi CPU Bound e I/O Bound'''
:: I processi si possono dividere in queste due categorie. I processi che utilizzano il processore per tempi più lunghi (per esempio quelli di calcolo scientifico) si chiamano CPU Bound mentre quelli che richiedono spesso interazioni e si fermano ad aspettare l'I/O si chiamano I/O Bound. Algoritmi di scheduling differenti possono favorire o sfavorire una delle due categorie. L'obbiettivo e trovare un algoritmo che sia ottimale per tutti i processi.
* '''Algoritmi di scheduling'''
** First come first served
:: Lo scheduler implementa una semplice coda dei processi che hanno richiesto l'esecuzione. E' semplice da capire e creare ma il tempo medio di attesa per un processo può essere lungo. Dipende molto dall'ordine in cui vengono avvicendati processi CPU bound e I/O Bound. Un processo CPU bound può creare un ''effetto convoglio'' e far dipendere il tempo di attesa di altri processi che sono I/O bound al suo tempo di esecuzione. Questo algoritmo non è quindi equo.
:* Shortest job first
:: Forse più correttamente nominato algoritmo ''shortest next CPU burst''. Ad ogni processo viene associato il suo tempo di esecuzione e viene scelto dalla ready queue sempre il processo con il tempo più basso. Per determinare il tempo di esecuzione a priori si utilizza una media esponenziale dei tempi di esecuzione dello stesso processo nel passato. [[File:Media_esponenziale.png]] ''t'' sono le misurazioni recenti mentre 'tau' sono la storia più ''remota''. Il parametro alfa determina quanto la media esponenziale sia basata sulla storia recente o su quella passata.
:* Shortest remaining time first
:: SJF può essere preemptive oppure no. Nel caso preemptive prende il nome di ''Shortest remaining time first''. Se un processo A è in esecuzione e arriva un'altro processo B con tempo di esecuzione minore allora A viene fermato e viene eseguito B. La priorità di A nella coda è ora il tempo stimato rimanente.
:* Round robin
:: E' definita un unità di tempo, di solito tra i 10 e i 100 millisecondi, e ogni processo ha un tempo massimo di esecuzione pari a questa unità. I processi vengono avvicendati a turno in una coda. Un processo termina l'esecuzione o per sua volontà (il tempo rimasto del quanto di tempo non è considerato) oppure perchè è scattato l'interval timer. Nell'ultimo caso il processo viene inserito in coda come se fosse un processo appena arrivato. La performance di questo algoritmo dipendono molto da che tipi di processi si gestiscono e dalla dimensione dell'unita di tempo. Se questa è larga allora l'algoritmo è più simile a FCFS mentre un'unita di tempo piccola porta a più context switch e quindi a più overhead. L'unità di tempo andrebbe decisa in proporzione al tempo di context switch.
:* Scheduling a priorità
:: Ad ogni processo è assegnata una priorità che si riflette nella priorità che ha il processo nella ready queue.
:: La priorità di un processo può essere influenzata da fattori interni (come i requisiti di memoria) o esterni al sistema operativo (come ''l'importanza'' di un processo). L'algoritmo può essere non preemptive o premtive, nel caso in cui interrompa il processo attuale se arriva un processo con più priorità.
:: L'SJF può essere visto come un caso particolare di cheduling a priorità, in cui la priorità e appunto inversamente proporzionale al tempo di esecuzione.
:: Un problema dello scheduling a priorità è la starvation, che può essere risolta con il meccanismo di ''aging'' in cui un processo aumenta di priorità proporzionalmente al tempo cui rimane nella ready queue.
:* Scheduler multilivello
:: Questo è lo scheduler più completo in quanto divide i processi in gruppi e utilizza differenti algoritmi per ogni gruppo.
:: Una tipica suddivisione è quella di processi foreground e background, rispettivamente I/O bound e CPU bound. Per ogni gruppo viene creata una coda apposita.

== Lezione del 2 marzo 2017 ==

'''Shell Scripting'''

'$' seguito da caratteri esegue una sostituzione, questa può essere:

'''ESEMPIO 1 (contenuto)'''

echo $SHELL

echo $USER

'''ESEMPIO 2 (comando)'''

echo $ls

'''ESEMPIO 2.1'''

du -s $(ls -d *es) //du -s prende come input l'output del comando compreso tra parentesi tonde

'''ESEMPIO 3 (wildcard)'''

echo * // tutti file/dir
echo *es // file/dir che terminanon con es
echo *[lg]es // file/dir che terminanon con les/ges
echo ????? // file/dir con 5 caratteri

Queste wildcard servono per poter individuare insiemi di file in un colpo solo.

'''ESEMPIO 4 ($ come sintassi riconosciuta da grep)'''

grep '>$' *.c // trova tutte le linee che terminano con '>' all'interno dei file .c

'''ESEMPIO 5 (PID)'''

echo $$ // restituisce PID dello script nel quale viene eseguito

'''ESEMPIO 6a'''

echo $1 $2 $3 >/tmp/tmpscript //scrive i 3 argomenti in tmpscript

cat /tmp/tmpscript //lettura tmpscript
rm -f /tmp/tmpscript //rimozione tmpscript

Se cerchiamo di lanciare quasi contemporaneamente lo script dell'esempio 6 in due shell differenti, lo script non funziona perchè lavorano sullo stesso file. Possiamo quindi ricorrere all'utilizzo di $$.

'''ESEMPIO 6b'''

echo $1 $2 $3 >/tmp/tmpscript$$

sleep 3 //in modo da poter lanciare lo script in un'altra shell
cat /tmp/tmpscript$$
rm -f /tmp/tmpscript$$

'''ESEMPIO 7'''
grep bash myscript.sh >& dev/null //ridireziono l'output di grep sul "null device"
echo $? //restituisce 0 se il comando precedente è stato eseguito correttamente, 1 altrimenti

'''Gli operatori >> e <<'''

>> è simile a > ma scrive alla fine del file invece che all'inizio. 
<< serve invece per inserire l'input di un comando direttamente nello script, come mostrato nel successivo esempio della mail.

'''ESEMPIO 8 (script per inviare mail)'''

#!/bin/bash

mail $1 << ENDOFMESSAGE
ciao $1 questa è una mail di prova
ENDOFMESSAGE //etichetta usata per indicare il termine del messaggio

Con

echo $1; echo $2; ls

raggruppiamo una sequenza di comandi sulla stessa riga

'''ESEMPIO 9((|| &&)'''

Gli operatori || e && possono essere utilizzati per processare più comandi consecutivamente.

command || die

gcc -o hwx hw.c && ./hwx

'''ESEMPIO 10 (sottoshell)'''

Una lista di comandi all'interno di () viene eseguita in una sottoshell. Le variabili all'interno della sottoshell non sono visibili al di fuori del blocco di codice nella sottoshell. Sono variabili locali.

(cd subdir; ls) //eseguo un comando in un'altra directory

'''Pushd e popd'''

Simili al comando ''cd'' ma pushd inserisce i percorsi visitati in una pila e tramite popd e possibile ripercorrere a ritroso le directory visitate.

'''ESEMPIO 11 (background jobs)
ping google.com & //esegue ping in background
jobs //mostra la lista dei jobs in esecuzione
//poniamo che l'output di jobs sia "[1]+ In esecuzione ping google.com &"
kill -9 %1 //termina il processo con identificatore 1
''bg'' repristina un processo fermato con CTRL+Z. 
''fg'' riporta in primo piano un processo mandato in background.

'''test e type'''

''test'' serve a comparare valori e controllare il tipo dei file. 
la sintassi ''[]'' è un alias di test.
if [ $$ -eq '10853' ] ; then echo "il processo corrente ha pid 10853"; else echo "il processo corrente non ha pid 10853"; fi;
//che è equivalente a
if test $$ -eq '10853'; then echo "il processo corrente ha pid 10853"; else echo "il processo corrente non ha pid 10853"; fi;
''type'' invece mostra l'origine di un comando, se sono integrati nella shell oppure è un programma a parte.

'''Switch'''
Sintassi degli switch in bash.
case expression in
pattern1 )
statements ;;
pattern2 )
statements ;;
...
esac
'''Comando cron''' 
''cron'' serve per eseguire operazioni pianificate. Gli script in /etc/init.d vengono eseguiti automaticamente da cron.

'''xarg''' 
xarg permette di eseguire un comando passandogli come parametri i valori letti da standard input.

'''uniq''' 
uniq può essere usato per trovare e eliminare righe duplicate.

'''wc''' 
''wc'' crea il ''word count'' di un file. Non conta solo le parole ma anche i caratteri e le righe.

'''diff e patch''' 
Il comando ''diff'' può essere utilizzato per mostrare le differenze tra due file testuali. E' utilizzato internamente da git. 
Patch serve per applicare un ''diff file'' a un altro file in modo da aggiornarlo.

== Lezione del 7 marzo 2017 ==
Una risorsa è ogni elemento utile all'elaborazione.
* '''Classificazione di risorse'''
** '''Fisiche e logiche'''
::Esempi:
::CPU, memoria e dispositivi sono risorse ''fisiche''.
::file, strutture dati, critical section sono risorse ''logiche''.
:* '''Fungibili'''
::Una risorsa è fungibile se è uguale prendere un bene o un'altro se sono dello stesso tipo. Richiedere un area di memoria o un altra è indifferente se tutte e due soddisfano i requisiti del processo. Richiedere file o dispositivi differenti invece cambia.
:* '''Assegnazione statica o dinamica'''
::L'assegnazione statica prevede che una risorsa sia monopolio di un processo.
:* '''Accetta richieste multiple o solo singole'''
:: Se può ricevere richieste d'uso da più processi e memorizzare/servire contemporaneamente le richieste oppure no.
:* '''condivisibili e non condivisibili'''
:: Un file in lettura è una risorsa condivisibile, più processi possono accedere contemporaneamente. Un file in scrittura invece è una risorsa non condivisibile perché potrebbe capitare una race condition.
:* '''bloccante e non bloccante'''
::Se l'accesso alla risorsa implica dei tempi di attesa relativamente lunghi al processo, la risorsa è da considerarsi bloccante.
:* '''prelasciabile o non prelasciabile'''
::Il processo può rilasciare in qualsiasi momento la risorsa e permetterne l'uso ad un altro processo? Una stampante e un esempio di rirosa non prelasciabile.
* '''Deadlock'''
:Un deadlock può avvenire in presenza di risorse bloccanti, non condivisibili, non prerilasciabili e con una situazione di attesa circolare.
:* '''detection: grafo di Holt '''
::I grafi di allocazione delle risorse, introdotti da Holt nel 1972 sono un buon modo per descrivere lo stato di un sistema e prevedere possibili deadlock. Ogni nodo rappresenta una risorsa o un processo. Di solito le risorse sono rappresentate da quadrati e i processi da cerchi. Un arco da un processo a una risorsa significa che quel processo ha richiesto un'istanza della risorsa. Un arco da una risorsa a un processo vuol dire che un'istanza di quella risorsa è stata assegnata al processo. 
::* ''' teorema dei cicli in grafi di Holt con un solo tipo di risorsa
:::Se il grafo non contiene cicli allora di sicuro non possono esserci deadlock.
:::Se il grafo contiene un ciclo allora può esserci un deadlock.
:::Se le risorse coinvolte in un ciclo hanno solo un'istanza o ogni loro istanza e coinvolta in un ciclo allora c'è di sicuro un deadlock.
:::Questo tecnica di permette di analizzare uno stato ''attuale'' di un sistema, ma dobbiamo trovare un modo per prevedere lo stato ''futuro'' del sistema e quindi prevedere i deadlock.
::* '''processo di riduzione
:::Per vedere lo stato di un sistema futuro possiamo usare un processo di riduzione del grafo di allocazione delle risorse.
:::Se una risorsa allocata a un processo può essere data dopo un certo periodo a un altro processo che l'ha richiesta allora si può fare una riduzione. Una riduzione consiste nell'eliminare un arco risorsa-processo perchè quel processo ha finito di utilizzare la risorsa oppure è stata prerilasciata e invertire un arco processo-risorsa di un processo che aveva richiesto la risorsa in un arco risorsa-processo.
:::Se un grafo può essere ridotto per tutti i suoi processi allora non può esserci deadlock.
:::Il problema di questo metodo/algoritmo è che nel momento che deallochiamo una risorsa a un processo e più processi avevano richiesto quella risorsa come scegliamo deterministicamente a quale processo assegnare la risorsa? Dovremmo provare tutti i casi per accertarsi che non si crei deadlock, ciò significa fare backtrack e perdere la polinomialità dell'algoritmo.
::* '''definizione di Knot
:::Il Knot è una caratteristica di un grafo che si verifica velocemente e permette di determinare possibili deadlock.
:::Un knot è un insieme di nodi in cui, per ogni nodo del knot, tutti e solo i nodi del knot sono raggiungibili da quel nodo.
:::Un knot è una condizione sufficiente ma non necessaria per i deadlock. Ciò vuol dire che possono capitare deadlock anche senza la presenta di un knot.
::* '''teorema dei knot nei grafi di Holt con più tipi di risorse
:* '''prevention'''
::Se il sistema cerca di non far verificare almeno una delle condizioni necessarie al deadlock allora questo non si verificherà mai.
::Questo però comporta anche sottoutilizzo delle risorse del sistema.
:* '''avoidance'''
::*'''Condizione di safety'''
:::Un sistema è in una condizione di safety se esiste una safe sequence.
:::Una safe sequence è una sequenza di processi dove per ogni richiesta di risorse di un processo questa richiesta può essere soddisfatta con le richieste disponibili al momento più tutte le risorse allocate precedentemente ai precedenti processi della sequenza.
:::Finchè c'è safety non possono verificarsi deadlock. In una situazione unsafe non è detto che capiti deadlock, ma è possibile.
::*'''algoritmo del Banchiere (mono e multivaluta).
:::L'algoritmo del banchiere si basa sul fatto che una banca non dovrebbe mai rimanere senza denaro da prestare ai clienti.
:::Vengono mantenute varie strutture dati come il capitale iniziale della banca, quanto è disponibile in cassa, quanto è stato prestato ad ogni cliente e quanto si può ancora prestare ad ogni cliente (in base al ''credito'' che ogni cliente ha).
:::La condizione di safety è data dalla condizione che bisogna mantenere almeno uno dei clienti soddisfacibile cioè che il denaro in cassa sia maggiore del possibile richiesta di prestito di almeno un cliente.
:::Se questa condizione non si verificasse alloca il banchiere deve aspettare che un cliente restituisca il prestito.
:::In caso di più valute (yen, dollari, euro, ...) che rappresentano i tipi diversi di risorse del sistema. Tutte le strutture dati aumentano di una dimensione, per esempio il denaro iniziale diventa un vettore.
::Teorema: il processo di controllo di safety non ha necessita' di backtrack.
:* '''Tecnica dell'ostrica/struzzo'''
::Un altro modo per gestire i deadlock e quello di ignorarli completamente.
::La maggior parte dei sistemi operativi utilizza questo metodo.
::Soprattuto in sistemi in cui è statisticamente determinato che i deadlock si verificano poco frequentemente i sistemi di prevenzione e avoidance costituirebbero un overhead troppo elevato.
::Sta allora alle singole applicazioni evitare di crearli.

== Lezione del 9 marzo 2017 ==

* awk
* phase2: prime fasi del boot
* python: presentazione del linguaggio ed analisi delle caratteristiche

== Lezione del 14 marzo 2017 ==
'''Gestione della memoria'''
* Binding a tempo di esecuzione, compilazione o esecuzione
* Memory Management Unit (MMU)
* Allocazione statica o dinamica
* Allocazione continua o non contigua
* Metodo delle partizioni fisse
: Problema della frammentazione interna.
* Metodo delle partizioni variabili
:Problema della frammentazione esterna.
:* Algoritmi di scelta dell'area di allocazione
:** First fit
:** Best fit
:** Worst fit
:** Next fit
:* Paginazione
:* Segmentazione
:* Memoria virtuale

== Lezione del 16 marzo 2017 ==
* '''Progetto phase2''': analisi del manuale di uARM
* '''Python''': funzioni, oop, @memoize, @trace

== Lezione del 21 marzo 2017 ==

La lezione del 21 marzo tace per impegno del docente.

== Lezione del 23 marzo 2017 ==
'''Memoria virtuale''': 
'''Algoritmi di paginazione:'''
Quando avviene un page fault serve un algoritmo per trovare la pagina "meno utile" in memoria a cui sostituire la pagina richiesta.
* '''FIFO''' viene sostituita la pagina che da più tempo è in memoria
* '''LFU''' ''Least Frequently Used'' contando il numero di richieste alla pagina possiamo calcolare quali sono le pagine più richieste e tenere solo quelle in memoria. Il problema è che una pagina potrebbe essere richiesta molto in una fase iniziale di un processo, quindi avere un rank elevato, però poi non essere più utilizzata. Una soluzione a questo problema è quella di shiftare a destra di 1 i bit del contatore degli utilizzi a intervalli regolari, ponendo questo in un decadimento esponenziale.
* '''LRU''' ''Least Recently Used'' si sostituisce la pagina che non è stata utilizzata da più tempo.
* '''Algoritmo ottimo''' algoritmo teorico utile per fare ''benchmark'' degli altri algoritmi. Se conosciamo a priori la ''reference string'' una sequenza che indica quali saranno le richieste delle pagine nel futuro, possiamo sostituire le pagine che per più tempo non saranno richieste, riducendo al minimo i page fault.
'''Anomalia di Belady'''
Abbiamo dimostrato che l'algoritmo FIFO all'aumentare della memoria può peggiorare di performance.

== Lezione del 28 marzo 2017 ==
'''Algoritmo second chance o dell'orologio''' 
'''Linking statico''' 
'''Loading dinamico''' 
'''Memoria secondaria''' 
'''Algoritmi di scheduling delle seek''' 
*'''FIFO'''
*'''SSF'''
*'''c-look'''

== Lezione del 30 marzo 2017 ==
'''Discussione sulle specifiche del progetto''' 
:Creazione pagina [[Specifiche_phase_2_2016/17]]
'''Python standard library'''
* libreria sys: Permette di prendere parametri da linea di comando. Si utilizza ''sys.argv''.
* libreria os: Permette di navigare nella gerarchia di directory con ''os.walk''.

== Lezione del 4 aprile 2017 ==
'''RAID''' 
(Redundant Array Inexpensive/Independent Disks)

l’idea principale nasce per ottenere maggiori performance (raid 0 ed 1), non maggiore affidabilità (raid 4 e 5).

* RAID0 (Striping): i dischi sono posti in sequenza.Vengono create le stripe, sequenze di bit che sono posti su n dischi sequenzialmente. Lo striping può essere a vari livelli, a livello di bit, di byte, di settore o di blocco. Quello più utilizzato e il livello di blocco. Cioè per scrivere un file che è composto da più blocchi si suddividono i blocchi in più dischi. Attenzione, file piccoli potrebbero sostare su una sola stripe, quindi su un solo disco.
:Il miglioramento di performance si paga in maggiore faultness. dipende dal costo dei dati salvati.

* RAID1 (mirroring): ogni disco ospita la copia dei dati. doppia velocità in lettura (teoricamente). Stessa velocita di scrittura.
: Size = ½ readSpeed = N wSpeed = ½ N FT = 1
* RAID10 = 1+0 striping su 2 mirror.

* RAID 2-3 (deprecated):Agisce sui singoli blocchi i dati vengono salvati in maniera sincrona con meccanismi di parità (hoffman per correzione di errori nel RAID2, ciclica per RAID3).

* RAID4: usa dischi normali, non agisce su singoli blocchi ma su stripe ampi.

parityMap = S0 XOR S1 XOR S2 XOR S3 (in caso di 4+1 dischi).

nel caso si rompa S4, i dati non avranno problemi. Se si rompesse un qualunque dei primi 4 dischi, basterà effettuare lo XOR degli altri e copiare tali dati su un nuovo HD.

S1 rotto.
new_S1 = S0 XOR S2 XOR S3 XOR P0123
Sopporta una sola rottura.

Per aggiornare il disco di parità in caso di modifica a S2 (chiamato ora S2’)

P0123 = P0123 XOR S2 XOR S2’.
il primo xor toglie il valore da P0123 di S2, il secondo XOR aggiunge il valore S2’.
in questo modo, aggiorno solo 2 dischi, e uso gli stessi in lettura per ricalcolare la parità.

Le parità ciclano su tutti i dischi. Esistono controller che effettuano RAID5, oppure e’ possibile ottenere le funzionalità raid via sistema operativo.

* RAID5:
:Senza fault
:Size = N-1/N, rspeed=(N-1), wspeed=(N-2), FT=1

I dischi RAID soffrono alquanto in caso di terremoti.

'''File System:''' 
Servizio per dare una interfaccia più comoda e generale per l’accesso alla memoria secondaria.

Nasce come informatizzazione delle pratiche di ufficio. le pratiche sono salvate in folders, fascicoli, poste poi nelle directories. come visualizzo questa struttura per l’utente? E ad i programmatori? come viene implementato?

Nasce l’idea di “aprire” i file. Nell'accedere da un programma ad il file-system (operazione non banale) si preferisce chiamare un’operazione di apertura, e utilizzare un descrittore al file per agire sul file richiesto.

La struttura di file/folder/directories possono inoltre supportare le astrazioni di condivisione e proprieta’.
Tutti i controlli sono effettuati sono in fase di apertura (in modo da migliorare le performance).

Quali attributi caratterizzano un file?
<ul>
<li>Name,</li>
<li>Type,</li>
<li>Location,</li>
<li>Size,</li>
<li>Ownership,</li>
<li>Protection,</li>
<li>Time stamp</li>
</ul>
UNIX opta per una scelta minimalista. Tutti i file sono stringhe di byte.
AFS (Apple) da un tag di tipo e di creator per ogni file

maggiore e’ il numero di tipi di file, maggiore supporto per essi, ma piu’ codice nel kernel.
I suffissi possono indicare ad altri programmi il tipo.

Semantica della coerenza vs Semantica delle sessioni (Andrew File System)

Per quali motivo vengono create le partizioni?
/var andrebbe in una nuova partizione per un fattore di sicurezza.

Cosa c’e’ effettivamente sul disco? Una sequenza di blocchi, il cui primo (boot block) ha spazio per il bootloader e la tabella delle partizioni (MBR), con 4 elementi. 4 record che indicano dove ogni partizione inizia e finisce. Si possono usare partizioni estese, usando le prime 3 e nella quarta tutto il resto.

Ogni partizione ha all'inizio un BootRecord.
L’ultima partizione contiene nel BootRecord le altre partizioni.
GBT consente di avere un numero arbitrario di partizioni.

Raizer FS,

Read only file systems.

Initrd, ISO9660.

Quando si costruisce l’immagine, in realtà si sta creando il file-system ISO9660.

Come gestire invece file che possono cambiare?
Allocazione indicizzata (a lista): creo un (o vari) blocco/i degli indici che punta ad i blocchi dati.
l’accesso diretto cresce come il logaritmo dell’ampiezza.
Allocazione concatenata (ad albero): (in fondo al blocco indico il successivo). Gestisce bene la dinamicità. Non piace perché’ non é per nulla efficiente l’accesso diretto.

Quali allocazioni usano i filesystem reali oggi?

fat: concatenata. I blocchi tengono solo i dati, esiste una file allocation table (vettore) che indica il prossimo blocco. I puntatori sono tutti vicini e quindi ponendo il vettore in cache, abbiamo disponibili diversi puntatori.

BerkleyFastFileSystem (progenitore dei EXT4…) usano allocazione indicizzata. Nasce per garantire performance ad i file piccoli. Nel descrittore del file (iNode) avra’ N (13 attualmente) puntatori. Uno, il numero 10, ad i blocchi, uno (11) indiretto alla tabella, uno (12) come duplice indiretto e il 13esimo come triplice indiretto.

I file hanno quindi una lunghezza massima. EX4 pero’ risolve indicizzando non i singoli blocchi ma le serie.

Gestione spazio libero

nella struttura indicizzata serve una struttura per tenere conto degli spazi liberi. Si puo’ usare una bitmap per tenere la contabilità degli spazi liberi e quelli utilizzati.

== Lezione del 6 aprile 2017 ==

File System. Ext2 e VFAT. Sicurezza, principi generali.

== Lezione del 11 aprile 2017 ==

Sicurezza: crittografia (chiave pubblica/chiave segreta) autorizzazione autenticazione firma elettronica.
Virus Worm Cavalli di Troia.

Attacchi buffer overflow e toctou.

== Lezione del 20 aprile 2017 ==

(tace per impossibilita' del docente)

== Lezione del 27 aprile 2017 ==

P2test (prestest2).

DIscussione specifiche.

== Lezione del 2 maggio 2017 ==
== Lezione del 4 maggio 2017 ==
* Discussione su proposta da parte degli studenti di modifiche al test di progetto
* Soluzione all'esercizio C1 del 2014-06-16 (Monitor)
* Soluzione all'esercizio 1 del [[http://www.cs.unibo.it/~renzo/so/pratiche/2015.05.29.pdf 2016-05-20]] ( C )
* Soluzione all'esercizio 2 del 2008-06-13 (Dimostrazione algoritmo di rimpiazzamento a stack)
* Soluzione all'esercizio 1 del [[http://www.cs.unibo.it/~renzo/so/compiti/2013.07.19.tot.pdf 2013-07-19]] (Monitor)

== Lezione del 9 maggio 2017 ==
*Esercizio 2 prova teorica 2014.09.24
*Esercizio g.1 prova teorica 2013.07.19
*Esercizio c1 e c2 prova teorica 2015.01.20(2014.01.20)
*Esercizio c2 2013.05.30

== Lezione del 11 maggio 2017 ==
== Lezione del 16 maggio 2017 ==
* Chiarimenti su svolgimento esame
* Commenti su recenti eventi (WannaCry)
* Visione di programma python per costruzione di stringhe palindrome con monitor
* Correzione esercizio g2 prova teorica 20170209
* Correzione esercizio 1 [[Prova pratica 2016.09.13]]
* Esercizio c2 prova teorica 20140122

== Lezione del 18 maggio 2017 ==

Prova pratica 2016.09.13

2017-05-16T13:24:53Z

FedericoB: /* Proposta di FedericoB */ Soluzione corretta con lock Posix funzionanti

[http://www.cs.unibo.it/~renzo/so/pratiche/2016.09.13.pdf Link al testo] (è sbagliata la data nel titolo ma il testo è quello giusto)
==Esercizio 1==
<source lang="text">
Scrivere un programma che mostri il funzionamento del file locking.
In particolare il programma cplk avra’ due argomenti che I pathname di due file. Il contenuto del primo file deve
essere copiato nel secondo usando la system call sendfile.
Prima di iniziare la copia occorre usare la system call fcntl per bloccare il file di output (write lock).
Completata la copia occorre chiamare nuovamente la fcntl per sbloccare il file.
Inserire un ritardo (sleep) con valore casuale da 1 a 10 secondi sia prima sia dopo aver sbloccato il file e
stampe di controllo che indichino quando il file viene bloccato e sbloccato.
In questo modo lanciando piu’ esecuzioni concorrenti con output sullo stesso file deve apparire che l’accesso in
scrittura e’ mutualmente esclusivo.
Es. di output:
$ cplk cplk.c out
locked attende da 1 a 10 sec
unlocked attende da 1 a 10 sec
$
</source>
===Soluzione di FedericoB===
<source lang="c">
#define _GNU_SOURCE

#include <unistd.h>
#include <stdlib.h>
#include <sys/sendfile.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <time.h>

int main(int argc, char* argv[]) {
if (argc == 3) {
//get file descriptors
int fdFile2 = open(argv[2], O_WRONLY);
int fdFile1 = open(argv[1], O_RDONLY);
//create structure for file locking
struct flock flock;
struct stat stat_buf;
fstat(fdFile1, &stat_buf);
//type = write lock
flock.l_type = F_WRLCK;
flock.l_start = 0;
//set l_start relative of beginning of file
flock.l_whence = SEEK_SET;
flock.l_len = stat_buf.st_size;
flock.l_pid = getpid();
fcntl(fdFile2, F_SETLKW, &flock);
//print "locked"
printf("locked\n");
//use sendfile for copy, use fdFile1 offset and copy all file 1
sendfile(fdFile2, fdFile1, NULL, stat_buf.st_size);
//wait for a random time between 1 and 10 seconds
srand(time(NULL));
int r = rand() % 10 + 1;
sleep(r);
//unclock second file
flock.l_type = F_UNLCK;
fcntl(fdFile2, F_SETLKW, &flock);
//print "unlocked"
printf("unlocked\n");
//wait for a random time between 1 and 10 second
r = rand() % 10 + 1;
sleep(r);
return 0;
} else {
printf("wrong number of arguments!");
return -1;
}
}
</source>

Prove pratiche

2017-05-16T12:33:39Z

FedericoB: Aggiunto link alla Prova pratica 2016.09.13

''Qui troverete alcune prove teoriche pratiche (laboratorio), in modo da poter discutere sull'elaborato''

''Le prove sono svolte da studenti e servono come base per la discussione. Le soluzioni possono essere errate''

[[Prova pratica 2017.01.17]]

[[Prova pratica 2016.05.31]]

[[Prova pratica 2016.09.13]]

[[Prova pratica 2015.05.20]]

[[Prova pratica 2015.01.21]]

[[Prova pratica 2014.09.25]]

[[Prova pratica 2014.07.17]]

[[Prova Pratica 2014.07.02]]

[[Prova Pratica 2014.06.17]]

[[Prova pratica 2014.05.29]]

[[Prova Pratica 2014.02.20]]

[[ProvaPratica 2014.01.23]]

[[ProvaPratica 2013.09.13]]

[[ProvaPratica 2013.07.18]]

[[ProvaPratica 2013.06.21]]

[[ProvaPratica 2013.05.29]]

[[ProvaPratica 2013.02.15]]

[[ProvaPratica 2013.01.25]]

[[ProvaPratica 2012.09.19]]

[[ProvaPratica 2012.07.17]]

[[ProvaPratica 2012.06.20]]

[[Prova Pratica 2012.05.30]]

[[ProvaPratica 2011.09.12]]

[[Prova Pratica 2011.06.22]]

[[ProvaPratica 2011.05.30]]

[[ProvaPratica 2011.01.19]]

[[ProvaPratica 2010.07.19]]

[[ProvaPratica_2010.07.12]]

[[ProvaPratica 2010.02.03]]

[[ProvaPratica 2009.09.23]]

[[ProvaPratica 2009.06.23]]

[[ProvaPratica 2009.02.12]]

[[ProvaPratica 2009.01.15]]

[[ProvaPratica 2005.02.10]]

[[Prova pratica 2002.01.24]]

Prova pratica 2016.09.13

2017-05-16T12:31:11Z

FedericoB: Creata pagina con soluzione da sistemare

[http://www.cs.unibo.it/~renzo/so/pratiche/2016.09.13.pdf Link al testo] (è sbagliata la data nel titolo ma il testo è quello giusto)
==Esercizio 1==
<source lang="text">
Scrivere un programma che mostri il funzionamento del file locking.
In particolare il programma cplk avra’ due argomenti che I pathname di due file. Il contenuto del primo file deve
essere copiato nel secondo usando la system call sendfile.
Prima di iniziare la copia occorre usare la system call fcntl per bloccare il file di output (write lock).
Completata la copia occorre chiamare nuovamente la fcntl per sbloccare il file.
Inserire un ritardo (sleep) con valore casuale da 1 a 10 secondi sia prima sia dopo aver sbloccato il file e
stampe di controllo che indichino quando il file viene bloccato e sbloccato.
In questo modo lanciando piu’ esecuzioni concorrenti con output sullo stesso file deve apparire che l’accesso in
scrittura e’ mutualmente esclusivo.
Es. di output:
$ cplk cplk.c out
locked attende da 1 a 10 sec
unlocked attende da 1 a 10 sec
$
</source>
===Proposta di FedericoB===
Non sono sicuro che funzioni. --[[User:FedericoB|FedericoB]] ([[User talk:FedericoB|talk]]) 14:31, 16 May 2017 (CEST)
<source lang="c">
#define _GNU_SOURCE

#include <unistd.h>
#include <stdlib.h>
#include <sys/sendfile.h>
#include <stdio.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <time.h>

int main(int argc, char* argv[]) {
if (argc == 3) {
//get file descriptors
int fdFile2 = open(argv[2], O_WRONLY);
int fdFile1 = open(argv[1], O_RDONLY);
//create structure for file locking
struct flock flock;
struct stat stat_buf;
fstat(fdFile1, &stat_buf);
//type = write lock
flock.l_type = F_WRLCK;
flock.l_start = 0;
//set l_start relative of beginning of file
flock.l_whence = SEEK_SET;
flock.l_len = stat_buf.st_size;
flock.l_pid = getpid();
fcntl(fdFile2, F_OFD_SETLKW, &flock);
//print "locked"
printf("locked\n");
//use sendfile for copy, use fdFile1 offset and copy all file 1
sendfile(fdFile2, fdFile1, NULL, stat_buf.st_size);
//wait for a random time between 1 and 10 seconds
srand(time(NULL));
int r = rand() % 10 + 1;
sleep(r);
//unclock second file
flock.l_type = F_UNLCK;
fcntl(fdFile2, F_OFD_SETLKW, &flock);
//print "unlocked"
printf("unlocked\n");
//wait for a random time between 1 and 10 second
r = rand() % 10 + 1;
sleep(r);
return 0;
} else {
printf("wrong number of arguments!");
return -1;
}
}
</source>

Prova pratica 2017.01.17

2017-05-15T14:55:59Z

FedericoB: Aggiunti testi esercizi

[http://www.cs.unibo.it/~renzo/so/pratiche/2017.01.17.pdf link al testo]
==Esercizio 1==
<source lang="text">
Scrivere un programma che conti I file ordinari e le directory presenti nel sottoalbero della directory passata come
parametro (o della directory corrente se non viene passato alcun parametro).
Ogni file o directory deve venir contato una sola volta anche se e’ presente con diversi nomi a causa dei link fisici.
Ogni altro tipo di file che non sia file ordinario o directory (e.g. socket, named pipe, file speciali, link simbolici)
devono essere ignorati.
</source>
===Soluzione del prof===
<syntaxhighlight lang=C>
#include <stdio.h>
#include <stdlib.h>
#include <dirent.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>

struct fileelem {
dev_t dev;
ino_t ino;
struct fileelem *next;
};

int addfile(struct fileelem **head, dev_t dev, ino_t ino) {
if (*head == NULL) {
*head = malloc(sizeof(struct fileelem));
(*head)->dev = dev;
(*head)->ino = ino;
(*head)->next = NULL;
return 1;
} else if ((*head)->dev == dev && (*head)->ino == ino) {
return 0;
} else {
return addfile(&((*head)->next), dev, ino);
}
}

int filt(const struct dirent *elem) {
if (strcmp(elem->d_name,".") == 0 ||
strcmp(elem->d_name,"..") == 0)
return 0;
else {
return 1;
}
}

int recscan(char *path, struct fileelem **head) {
struct dirent **list;
int count = 0;
int n = scandir(path, &list, filt, alphasort);
int i;
for (i = 0; i < n; i++) {
struct stat buf;
char *filepath;
asprintf(&filepath,"%s/%s",path,list[i]->d_name);
stat(filepath, &buf);
switch (buf.st_mode & S_IFMT) {
case S_IFREG:
count += addfile(head, buf.st_dev, buf.st_ino);
printf("file %s %ld %ld ... %d\n",filepath,buf.st_dev,buf.st_ino,count);
break;
case S_IFDIR:
count = count + recscan(filepath, head);
break;
}
free(filepath);
free(list[i]);
}
free(list);
return count;
}

int main(int argc, char *argv[]) {
struct fileelem *head = NULL;
int result;
if (argc > 1)
chdir(argv[1]);
result = recscan(".", &head);
printf("Num of independent files: %d\n", result);
}

</syntaxhighlight>

==Esercizio 3:==
<source lang="text">
Scrivere uno script che faccia il merge dei contenuti due directory:
merge a b c
Tutti i file (non le directory) esistenti in a e in b devono essere spostati in c. Nel caso due file con lo stesso nome
compaiano sia in a sia in b, il file spostato in c deve essere quello piu' recentementente modificato, l’altro deve
rimanere nella directory di origine.
</source>
===Python===
====Soluzione di Ossigeno====

<syntaxhighlight lang=Python>
def merge(): # dati due path di due directory, fa la merge in una terza directory
# 1=pathprimo 2=pathsecondo 3=pathdestinazione
if (len(sys.argv) > 3):
for d, _, fl in os.walk(sys.argv[1]):
for f in fl:
path = os.path.join(d, f)
if (os.path.isfile(path)): # e' un file e non una directory allora copio tutto
shutil.copy2(path, sys.argv[3])
for d, _, fl in os.walk(sys.argv[2]):
for f in fl:
path = os.path.join(d, f)
if (os.path.isfile(path)): # e' un file e non una directory in path2
esistenza = os.path.join(sys.argv[3], f)
if (not os.path.isfile(esistenza)): # se non esiste un file con quel nome
shutil.copy2(path, sys.argv[3])
else:
if (os.stat(path).st_mtime > os.stat(
esistenza).st_mtime): # e' piu recente tempo del file in path2 rispetto a path3
shutil.copy2(path, sys.argv[3])
else:
print("Mancano degli argomenti")
</syntaxhighlight>
===Bash===
====Soluzione di Gabriele Calarota====
<syntaxhighlight lang=Bash>
#!/bin/bash

if [ $# -lt 3 ] ; then
echo "ERROR: example merge a b c"
exit 1
fi

a=$1
b=$2
c=$3
tmp_file=file_tmp

touch $tmp_file

find $a -type f -print0 | xargs -0 basename -a >> $tmp_file
find $b -type f -print0 | xargs -0 basename -a >> $tmp_file

#univoci
#echo "UNIQ"
sort $tmp_file | uniq -u | while read line
do

#now $line contains the basename of the file
ls "$a/$line" &>/dev/null && mv -v "$a/$line" "$c/$line"
ls "$b/$line" &>/dev/null && mv -v "$b/$line" "$c/$line"
done

#echo "DOUBLE"
sort $tmp_file | uniq -d | while read line
do
#now $line contains the basename of both of the filename
file1="$(stat -c %Y $a/$line)"
file2="$(stat -c %Y $b/$line)"
if [ $file1 -lt $file2 ] ; then
#echo "$line chose from $b"
mv -v "$b/$line" "$c/$line"
else
#echo "$line chose from $a"
mv -v "$a/$line" "$c/$line"
fi
done

rm $tmp_file
</syntaxhighlight>
--[[User:GabrieleCalarota|GabrieleCalarota]] ([[User talk:GabrieleCalarota|talk]]) 12:17, 15 May 2017 (CEST)

Prova pratica 2015.05.20

2017-05-12T08:10:36Z

FedericoB: Aggiunta soluzione esercizio 2

[http://www.cs.unibo.it/~renzo/so/pratiche/2015.05.29.pdf Link al testo]

==Esercizio 1==
<source lang="text">
Scrivere un programma catsig che copi lo standard input nello standard output (come il comando cat senza
parametri, per intenderci) e che stampi la scritta “ho ricevuto un segnale” quando riceve un segnale SIGUSR1.
La particolarita' di questo programma e' che per la gestione dei segnali deve usare la chiamata di sistema
signalfd (e non la signal o la sigaction)
</source>

=== Soluzione di FedericoB===
<source lang="C">
#include <unistd.h>
#include <sys/signalfd.h>
#include <signal.h>
#include <poll.h>
#include <stdio.h>

int main(int argc, char* argv[]) {
//declare a mask for signal
sigset_t mask;
//initialize signal mask
sigemptyset(&mask);
sigaddset(&mask, SIGUSR1);
//create a file descriptor for signal USR1
int signalFileDescriptor = signalfd(-1, &mask, 0);
//remove default handler for SIGURS1
sigprocmask(SIG_BLOCK, &mask, NULL);
struct pollfd pollstruct[2];
pollstruct[0].fd = signalFileDescriptor;
pollstruct[0].events = POLLIN;
pollstruct[1].fd = STDIN_FILENO;
pollstruct[1].events = POLLIN;
while (1) {
poll(pollstruct, 2, -1);
//is signal USR1 is received
if (pollstruct[0].revents & POLLIN) {
struct signalfd_siginfo siginfo;
//read signal information from signal file descriptor
read(signalFileDescriptor, &siginfo, sizeof(struct signalfd_siginfo));
printf("ho ricevuto un segnale\n");
//set event as handled
pollstruct[0].revents = 0;
}
//if there is something to read in standard input
if (pollstruct[1].revents & POLLIN) {
char character;
//read one character until there is a character to read
while (read(fileno(stdin), &character, 1) > 0) {
//print that character to standard output
write(fileno(stdout), &character, 1);
}
//set event as handled
pollstruct[1].revents = 0;
}
}
}
</source>

==Esercizio 2==
<source lang="text">
Ora, prendendospunto dall'esercizio 1 occorre scrivere due programmi:
sigsend e sigreceive.
Sigreceive non ha come parametri. Per prima cosa stampa il suo pid poi entra in un ciclo in cui:
• aspetta un segnale SIGUSR1
• stampa su stdout (visualizza) il file con nome /tmp/giroXXXX (dove XXXX e' il proprio pid)
• cancella il file /tmp/giroXXXX
• Manda un segnale SIGUSR1 al processo dal quale lo ha ricevuto nella operazione due righe sopra
questa.
Sigreceive termina quando riceve in SIGUSR2.
Sigsend ha come parametro il pid del processo ricevente. Per ogni riga posta in input da stdin fa le seguenti azioni:
• crea un file /tmp/giroXXXX (dove XXXX e' il pid del processo ricevente), vi scrive la riga letta e lo chiude.
• Spedisce un segnale SIGUSR1 al ricevente
• Aspetta dallo stesso un SIGUSR1.
Quando lo stdin termina (^D da tastiera) manda un SIGUSR2 al ricevente.
All'attivazione scrive nel file il proprio pid e aspetta un segnale sigusr1.Quando riceve il segnale legge
Anche in questo esercizio occorre usare solo la signalfd e non la signal o la sigaction.
</source>
===Soluzione di FedericoB===
sigreceive
<source lang="C">
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/signalfd.h>
#include <signal.h>
#include <poll.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {
int pid = getpid();
printf("pid: %d\n",pid);
char* path;
//create path with format giroXXXX
asprintf(&path, "/tmp/giro%d", pid);
sigset_t mask;
//initialize signal mask
sigemptyset(&mask);
sigaddset(&mask, SIGUSR1);
sigaddset(&mask, SIGUSR2);
//block default handler for SIGUSR1 and SIGUSR2
sigprocmask(SIG_BLOCK, &mask, NULL);
int fd;
//get a file descript for signal SIGUSR2 and SIGUS2
fd = signalfd(-1,&mask,0);
//create a poll structur for waiting signal USR1 and USR2
struct pollfd polls = {.fd = fd,.events=POLLIN};
//bool for checking is a sigsr2 arrived
int sigusr2 = 0;
while (!sigusr2) {
//wait for signal
poll(&polls,1,-1);
//if a signal arrived
if (polls.revents & POLLIN) {
struct signalfd_siginfo siginfo;
//read signal information from signal file descriptor
read(fd, &siginfo, sizeof(struct signalfd_siginfo));
if (siginfo.ssi_signo == SIGUSR1) {
FILE* file = fopen(path, "r");
if (file!=NULL) {
char* buffer = malloc(50);
//read from file
fgets(buffer, 50, file);
//print to standard output
printf("%s", buffer);
free(buffer);
fclose(file);
//remove file
remove(path);
//send a USR2 signal to sender of signal
kill(siginfo.ssi_pid, SIGUSR2);
} else {
printf("Error opening the file %s \n",path);
}
} else if (siginfo.ssi_signo == SIGUSR2 ) {
sigusr2 = 1;
}
polls.revents = 0;
}
}
return 0;
}
</source>
sigsend
<source lang="C">
#define _GNU_SOURCE
#include <unistd.h>
#include <sys/signalfd.h>
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char* argv[]) {
if (argc == 2) {
//get pid from program arguments
int receiverPid = atoi(argv[1]);
char* path;
//create path with format giroXXXX
asprintf(&path, "/tmp/giro%d", receiverPid);
char* buffer;
do {
buffer = malloc(200);
//read standard input
buffer = fgets(buffer, 200, stdin);
//fgets return NULL on ^D
if (buffer != NULL) {
FILE* file = fopen(path, "w");
if (file != NULL) {
fputs(buffer, file);
free(buffer);
fclose(file);
//send signal SIGURS1 to receiver
kill(receiverPid, SIGUSR1);
sigset_t mask;
//initialize signal mask
sigemptyset(&mask);
sigaddset(&mask, SIGUSR2);
//block default handler for SIGUSR2
sigprocmask(SIG_BLOCK, &mask, NULL);
int sig;
//wait for a SIGURS2
sigwait(&mask, &sig);
} else {
printf("Error opening the file %s \n", path);
}
}
} while (buffer != NULL);
//send a SIGUSR2 to receiver
kill(receiverPid, SIGUSR2);
} else {
printf("Parameters error: pid required\n");
}
return 0;
}
</source>

Prove pratiche

2017-05-11T12:36:33Z

FedericoB: Aggiunto link Prova pratica 2015.05.20

''Qui troverete alcune prove teoriche pratiche (laboratorio), in modo da poter discutere sull'elaborato''

''Le prove sono svolte da studenti e servono come base per la discussione. Le soluzioni possono essere errate''

[[Prova pratica 2017.01.17]]

[[Prova pratica 2015.05.20]]

[[Prova pratica 2015.01.21]]

[[Prova pratica 2014.09.25]]

[[Prova pratica 2014.07.17]]

[[Prova Pratica 2014.07.02]]

[[Prova Pratica 2014.06.17]]

[[Prova pratica 2014.05.29]]

[[Prova Pratica 2014.02.20]]

[[ProvaPratica 2014.01.23]]

[[ProvaPratica 2013.09.13]]

[[ProvaPratica 2013.07.18]]

[[ProvaPratica 2013.06.21]]

[[ProvaPratica 2013.05.29]]

[[ProvaPratica 2013.02.15]]

[[ProvaPratica 2013.01.25]]

[[ProvaPratica 2012.09.19]]

[[ProvaPratica 2012.07.17]]

[[ProvaPratica 2012.06.20]]

[[Prova Pratica 2012.05.30]]

[[ProvaPratica 2011.09.12]]

[[Prova Pratica 2011.06.22]]

[[ProvaPratica 2011.05.30]]

[[ProvaPratica 2011.01.19]]

[[ProvaPratica 2010.07.19]]

[[ProvaPratica_2010.07.12]]

[[ProvaPratica 2010.02.03]]

[[ProvaPratica 2009.09.23]]

[[ProvaPratica 2009.06.23]]

[[ProvaPratica 2009.02.12]]

[[ProvaPratica 2009.01.15]]

[[ProvaPratica 2005.02.10]]

[[Prova pratica 2002.01.24]]

Prova pratica 2015.05.20

2017-05-11T12:14:29Z

FedericoB: Aggiornata soluzione es 1 dopo discussione in aula

Prova pratica 2015.05.20

2017-05-11T07:58:29Z

FedericoB: Creata pagina con proposta di soluzione esercizio 1

ProvaPratica 2013.05.29

2017-05-10T16:16:03Z

FedericoB: Aggiunto link e testo del es 1

[http://www.cs.unibo.it/~renzo/so/pratiche/2013.05.29.pdf Link al compito]
==Esercizio 1==

<source lang="text">
Scrivere un programma testeventfd che faccia uso della system call eventfd.
In particolare il programma deve eseguire una fork, quando l'utente digita un numero letto dal processo padre, il processo
figlio deve stampare un numero uguale di x.
$ testeventfd
3
x
x
x
2
x
x
</source>

===Soluzione di GiuliaN.===

<syntaxhighlight lang="C">
#include <sys/eventfd.h>
#include <stdio.h>
#include <unistd.h>

#define BUFFSIZE 10

int main(int argc, char *argv[]){
int efd,n,i;
char buf1[BUFFSIZE];
char buf2[BUFFSIZE];

do{
efd = eventfd(0,0);
}while(efd<0);

while(1){
if(fork()){ /*padre*/
read(0,buf1,sizeof(buf1)); /*0 indica lo standard input*/
write(efd, buf1, sizeof(buf1));
}

else{ /*figlio*/
read(efd, buf2, sizeof(buf2));
n=atoi(buf2);
for(i=0; i<n; i++) printf("x\n");
}
}
}
</syntaxhighlight>
GiuliaN. con grande aiuto da parte dei colleghi

===Soluzione del Prof. Davoli===
(visto a lezione , soluzione del Prof. Davoli ricopiata da Pirata_20131203)
<syntaxhighlight lang="C">
#include <sys/eventfd.h>
#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
#include <unistd.h>

#define BUFFSIZE 10

int main(int argc, char *argv[]){
int efd , n , i;
uint64_t a , b;
if ( ( efd = eventfd( 0 , EFD_SEMAPHORE ) ) < 0 )
exit( 1 );
if ( fork() > 0 ){
while ( 1 ) {
uint64_t a;
scanf( "%lld" , &a );
write( efd , &a , sizeof( a ) );
}
}
else {
while ( 1 ) {
uint64_t b;
read( efd , &b , sizeof( b ) );
printf( "x\n" );
}
}
}
</syntaxhighlight>

===Soluzione di Pierg===
<source lang="c">
#include <sys/eventfd.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <stdint.h>

int main (int argc, char *argv[]) {

int efd, i;
long long unsigned int val;
ssize_t s;

/* Check for eventfd error */
efd = eventfd(0, 0);
if (efd == -1) {
perror("Eventfd Error");
}

/* Use fork to move eventfd form parent to child */
switch (fork()) {

case 0:
/* Read parent event */
s = read(efd, &val, sizeof(long long unsigned int));

if (s != sizeof(long long unsigned int)) {
perror("Read Error");
exit(EXIT_FAILURE);
}

/* For is used to print the 'x' of the argument passed by terminal */
for (i = (int)val; i > 0; i--) {
printf ("x\n");
}

exit(EXIT_SUCCESS);

/* Check for error */
case -1:
perror("Fork Error");
exit(EXIT_FAILURE);

default:
/* Wait for number */
printf ("Inserisci un intero diverso da 0: \n");
scanf ("%llu", &val);

/* Write parent event */
s = write(efd, &val, sizeof(long long unsigned int));

if (s != sizeof(long long unsigned int)) {
perror("Write Error");
exit(EXIT_FAILURE);
}

exit(EXIT_SUCCESS);
}
}
</source>

===Soluzione di Maldus===
Semaforo implementato usando un altro eventfd.
<source lang="c">
#include <stdio.h>
#include <sys/eventfd.h>
#include <inttypes.h>
#include <sys/types.h>
#include <signal.h>

int main(){
pid_t son ;
int ed1 , ed2 , i;
uint64_t x = 1;
int y = 1 ;
ed1 = eventfd(0,0) ; /*eventfd usato per la comunicazione effettiva del numero*/
ed2 = eventfd( 1 , EFD_SEMAPHORE ) ; /*eventfd usato come semaforo*/
switch( son = fork() ){
case 0:
while( 1 ){
read( ed1 , &x , 8) ; /*se ci sono dei dati li legge*/
for(i = x ; i > 0 ; i--) printf( "x" ) ;
printf("\n");
write(ed2 , &y , 8 ) ; /*dopo la lettura dei dati, dà il via libera sul semaforo per scrivere di nuovo*/
}
return 1;
default:
while( x ){
read( ed2 , &y , 8 ) ; /*si blocca sul semaforo se i dati non sono ancora stati letti*/
scanf("%" PRIu64 , &x) ;
write(ed1 , &x , 8 ) ; /*scrittura dei dati*/
}
kill(son ,SIGTERM);
return 0 ;
}
}
</source>

==Esercizio 2==

===Soluzione di Eduardo Santarelli===

<syntaxhighlight lang="C">
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/eventfd.h>

#define SIZE 64

int main(int argc, char **argv){
int efd_parent, efd_child;
pid_t pid;

efd_parent = eventfd(0, 0);
efd_child = eventfd(0, 0);

pid = fork();
if(pid < 0){
perror("Fork error. ");
exit(EXIT_FAILURE);
}
/* parent */
if(pid){
int okToWrite = 1;
ssize_t n;
char buf[SIZE];

for(;;){
if(okToWrite){
scanf("%s", buf);

n = write(efd_parent, buf, SIZE);
if(n < 0){
perror("Parent: write error.");
exit(EXIT_FAILURE);
}
okToWrite = 1-okToWrite;
}
else{
n = read(efd_child, buf, SIZE);
if( n < sizeof(uint64_t) ){
printf("Parent: something bad happened");
exit(EXIT_FAILURE);
}

printf("padre: %s\n", buf);
okToWrite = 1-okToWrite;
}
}
close(efd_parent);
}
/* child */
else{
int okToWrite = 0;
char buf[SIZE];
int n;

for(;;){
if(okToWrite){
scanf("%s", buf);

n = write(efd_child, buf, SIZE);
if(n < 0){
perror("child: write error.");
exit(EXIT_FAILURE);
}
okToWrite = 1-okToWrite;
}
else{
n = read(efd_parent, buf, SIZE);
if( n < sizeof(uint64_t) ){
printf("Child: something bad happened");
exit(EXIT_FAILURE);
}
printf("figlio: %s\n", buf);
okToWrite = 1-okToWrite;
}
}
close(efd_child);
}

return EXIT_SUCCESS;
}
</syntaxhighlight>
- Eduardo

==Esercizio 3==

===Soluzione di Tommaso Ognibene(Python 3)

<syntaxhighlight lang="Python">
'''
Prova Pratica di Laboratorio di Sistemi Operativi
29 maggio 2013
Esercizio 3

URL: http://www.cs.unibo.it/~renzo/so/pratiche/2013.05.29.pdf

@author: Tommaso Ognibene
'''

import os, sys

def Main(argv):
# Check number of arguments
if len(argv) != 2:
print("The function requires one argument to be passed in.")
return

# Check parameters
topDir = str(sys.argv[1])
if not os.path.isdir(topDir):
print("The parameter should be an existing directory.")
return

# Build a dictionary with key-value pair {file extension - total size}
extensionSize = { }
GetSize(topDir, extensionSize)

# Print results
PrintResults(extensionSize)

def GetSize(topDir, extensionSize):
for dirPath, dirNames, files in os.walk(topDir):
for file in files:
# 'example.mp3' -> ['example', 'mp3']
# 'example.tar.gz' -> ['example', 'tar', 'gz']
parts = file.split('.')
# ['example', 'mp3'] -> ['mp3']
# ['example', 'tar', 'gz'] -> ['tar', 'gz']
parts = parts[1:]
# ['mp3'] -> '.mp3'
# ['tar', 'gz'] -> '.tar.gz'
fileExtension = ".{0}".format(".".join(str(part) for part in parts))

# Compute the size in Bytes and update the dictionary
filePath = os.path.join(dirPath, file)
fileSize = os.path.getsize(filePath)
extensionSize[fileExtension] = extensionSize.get(fileExtension, 0) + fileSize

# Print results
def PrintResults(extensionSize):
for key, value in sorted(extensionSize.items()):
print('{0}: {1} Bytes.'.format(key, value))

if __name__ == "__main__":
sys.exit(Main(sys.argv))
</syntaxhighlight>

===Soluzione di Fede(python 3)===

<syntaxhighlight lang="Python">
import os, sys, copy

def dotsubstr(a):#restituisce la sottostringa .suffisso
#fcd = os.listdir('{0}'.format(arg1))
i=0
try:
while a[i]!='.':
i=i+1
return a[i:]
except IndexError:
return -1

def compliarg(li,arg):#restituisce una lista di tutti gli elementi contenenti la sottostringa arg come suffisso
res=[]
while li != []:
a=li.pop()
if a.endswith(arg): res.append(a)
return res

def listremintsect(l2,l1):#restituisce una lista res = l1 - intersezione di l1 ed l2
res=[]
while l1 != []:
a=l1.pop()
if not a in l2: res.append(a)
return res

def createpathlist(c,path):#restituisce una lista di path 'path' relativi ai file contenuti in c.
res = []
while c != []:
res.append('{0}/{1}'.format(path,c.pop()))
return res

def totsizes(d): #data una lista d di path restituisce la somma di tutti i size di d
res = 0
while d != []:
a = d.pop()
if os.path.isfile('{0}'.format(a)):
res = res + os.path.getsize('{0}'.format(a))
return res

def listsubstr(arg): #ritorna un dizionario del tipo diz[str(suffisso)] = int(size relativo al suffisso)
res = {}
fcd = os.listdir('{0}'.format(arg))
while fcd != []:
fcdtmp=copy.deepcopy(fcd) #BUGGONE SENZA COPY!!!!!!
a = fcd.pop()
b = dotsubstr(a)
if b == -1: continue
else: pass
c = compliarg(fcdtmp,b)
s=copy.deepcopy(c) #!!!!!!!!!!!!!!!!!!!!!!!!!
d = createpathlist(c,arg)
res[b] = totsizes(d)

fcd = listremintsect(s,fcd)

return res

try:
res = listsubstr(sys.argv[1])
a=list(res.keys())
while a != []:
b = a.pop()
print('{0}:\t{1}'.format(b,res[b]))
except OSError:
print("Could not solve path")

</syntaxhighlight>

===Soluzione in bash(Pirata & Fede)===

<syntaxhighlight lang="bash">
#! /bin/bash

for f in "$1"/*.* ; do
somma=0
ext=${f##*.}
for file in *."$ext"
do
somma=$(expr $somma + $(stat -c%s "$file"))
done
echo -n "size of file with extension "$ext" : "
echo "$somma"
done
</syntaxhighlight>
Per (Pirata & Fede) -Bash-: ci siamo quasi...però forse rifate gli stessi calcoli un po' di volte in più del necessario ;-) (am_20131127).

===Soluzione di Eduardo Santarelli (python)===

<syntaxhighlight lang="Python">
#!/usr/bin/env python3
#
# Prova Pratica di Lab SO 2013.05.29
# Es. 3
# Eduardo Santarelli
#####################################

import os, sys

# return the suffix of file named fname, if present.
# return boolean value False otherwise
def get_suffix(fname):
if '.' in fname:
separator = fname.find('.')
return fname[separator : ]
else:
return False

# Place a file in a dictionary. Each key corresponds
# to a specific suffix, its value is a list of all the
# file with that suffix
def build_dict(item, suffix):
if suffix in all_files:
all_files[suffix].append(item)
else:
all_files[suffix] = []
all_files[suffix].append(item)

# For each suffix key in the dictionary,
# calculates the total size of the files
# in the corresponding list
def size_of_entry(file_list):
size = 0
for item in file_list:
size += os.path.getsize(item)
return size

# This dictionary will contain a key for each suffix,
# associated with a list of all the files ending with
# that suffix
all_files = dict()

# Go to target directory and build a list containing all filenames
try:
target_dir = sys.argv[1]
except:
target_dir = '.'
os.chdir(target_dir)
dir_list = os.listdir('.')

# For each file call get_suffix and then build_dict
# (unless get_suffix returns False)
for item in dir_list:
suffix = get_suffix(item)
if not suffix:
pass
else:
build_dict(item, suffix)

for key in all_files :
print("{0}: {1} Bytes".format(key, size_of_entry(all_files[key])))
</syntaxhighlight>
-Eduardo
--edit: dir_list = os.listdir(target_dir) non funzionava bene coi path relativi.
Ora os.listdir('.') dovrebbe andare bene.

ProvaPratica 2009.02.12

2017-05-10T07:44:36Z

FedericoB: Aggiunte soluzioni di altri studenti

[http://www.cs.unibo.it/~renzo/so/pratiche/2009.02.12.pdf Link al testo]

== Esercizio 1 ==

===Soluzione di Stefano92===
<source lang="text">
Scrivere un programma C denominato “invarg” che esegua il programma passato
come parametro invertendo gli argomenti.
Esempio:
invarg cat a b c
deve avere l'effetto di
cat c b a
</source>
<syntaxhighlight lang="C">
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

void usage()
{
printf("usage: ./invarg.out EXEC_NAME [ARG1] [ARG2] ... [ARGN]\n");
}

int main(int argc,char* argv[])
{
char* tmp_i,*tmp_x;
int x=(argc-1),i=2;
if (argc<2)
{
usage();
return(1);
}
while(i<x)
{
tmp_i=argv[i];
tmp_x=argv[x];
argv[i]=tmp_x;
argv[x]=tmp_i;
i++;
x--;
}
for(i=0;i<argc-1;i++)
argv[i]=argv[i+1];

argv[argc-1]=NULL;
argc--;
execvp(argv[0],argv);
//equivalentemente avrei potuto lanciare execvp(argv[1],argv+1) evitando di modificare argv[]
return 0;

}
</syntaxhighlight>

stefano92

===Soluzione di Maldus===
<source lang="c">
#include <stdio.h>
#include <stdlib.h>

int main(int argc , char* argv[]){
char *nargv[argc-1] ; /*nargv è il vettore degli argomenti da passare al programma da eseguire*/
int i , j ; /*puntatori che scorrono, rispettivamente, argv ed nargv per riempire correttamente nargv*/
nargv[0] = argv[1] ; /*il primo valore di nargv deve essere il programma chiamato, l'ultimo deve essere NULL*/
nargv[argc-1] = NULL ;
for( i = argc - 1 , j = 1 ; i > 1 , j < (argc - 1) ; i-- , j++ ) nargv[j] = argv[i] ; /*metto in nargv (dal secondo elemento in poi) gli argomenti presenti
in argv in ordine invertito*/
execvp( nargv[0] , nargv ) ; /*eseguo il programma (il cui nome è contenuto in nargv[0]) passandogli nargv come vettore di parametri*/
fprintf( stderr , "programma errato\n" ) ; /*se ci troviamo in questo punto significa che la chiamata a execvp è fallita, probabilmente
perchè il programma indicato non è stato trovato*/
exit(1) ;
}
</source>

===Soluzione di Eddy===
<source lang="c">
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>

void scambia_ordine(int argc, char **argv, int j);

int main(int argc , char* argv[])
{
if (argc < 2) return 2;
argv++; argc--;
scambia_ordine(argc, argv, 1);
execvp(argv[0], argv);
perror("execvp");
return 3;
}

/* piccola funzione ricorsiva che:
* -memorizza in tmp gli argomenti dalla fine
* -assegna ad argv in ordine inverso
*
* non scambia il primo argomento
*/
void scambia_ordine(int argc, char **argv, int j)
{
char *tmp;
if (argc > 1){
tmp = argv[argc-1];
scambia_ordine (argc-1, argv, j+1);
argv[j]=tmp;
}

}
</source>
[[User:Eddy|Eddy]] ([[User talk:Eddy|talk]]) 21:00 Saturday, 22 November 2014 (CET)

===Soluzione di GFede===
<source lang="c">
#include <stdio.h>
#include <unistd.h>
#include <errno.h>

void scambia(int offset, int argc, char* argv[]);

int main(int argc, char* argv[])
{
if(argc <= 1)
{
printf("Usage: invarg.exe command [arguments...]\n");
return 2;
}
scambia(2, argc - 1, argv);

execvp(argv[1], argv + 1);
perror("execvp");
return 1;
}

/**
* Scambia le stringhe all'interno dell'array
* void scambia
* int offset Indice da cui iniziare a scambiare
* int argc Numero di valori nell'array (Compreso l'offset)
* char* argv[] array di stringhe da scambiare
*/
void scambia(int offset, int argc, char* argv[])
{
int i;
char* tmp;
for( i = offset; i < argc - i + offset; i++ )
{
tmp = argv[i];
argv[i] = argv[argc - i + offset];
argv[argc - i + offset] = tmp;
}
}
</source>

===Soluzione di LorenzoV===
<source lang="c">
#include <stdlib.h>
#include <stdio.h>

void swap(char **p, char **q){ // La swap modifica solo i puntatori
char *tmp;
tmp=*p;
*p=*q;
*q=tmp;
}

int main(int argc, char* argv[]){
char **begin, **end;
if (argc<3){
fprintf(stderr, "Usage:\n\t%s command ...arguments...\n", argv[0]);
exit(1);
}
begin=argv+2;
end=argv+argc-1;
while (begin<end){ // Inverte i parametri passati al comando
swap(begin, end);
begin++;
end--;
}
execvp(argv[1], argv+1);
return 0;
}
</source>
--[[User:LorenzoV|LorenzoV]] ([[User talk:LorenzoV|talk]]) 18:35, 25 November 2014 (CET)

===Soluzione di BoldrinD===
<source lang="c">
#include <stdio.h>
#include <unistd.h>
#include <errno.h>

void invarg(int Qparametri, char* Rargv[], char* argv[]);

int main(int argc, char* argv[]){
int Qparametri=argc-1;
char *Rargv[Qparametri];
invarg(Qparametri, Rargv, argv);
printf("%s\n","il nuovo vettore dei parametri è stato creato con successo");
execvp(Rargv[0], Rargv);
perror("execvp");
return 1;

}

void invarg(int Qparametri, char* Rargv[], char* argv[]){
Rargv[0]=argv[1];
Rargv[Qparametri]=NULL;
int i=2;
while(argv[i]!=NULL){
Rargv[Qparametri-1]=(argv[i]);
i++;
Qparametri--;
}

}
</source>

===Soluzione di AleZ===
<source lang="c">
#include <stdio.h>
#include <stdlib.h>

int main (int argc, char* argv[]) {
if (argc == 1) { // Non è stato passato alcun comando per la execvp
fprintf(stderr, "Error: Segmentation fault\nUsage: [command] [arguments...]\n");
return(EXIT_FAILURE);
}
char* tmp[argc]; // vettore che conterrà gli argomenti scambiati
int i = 0;
tmp[0] = argv[1]; // per convenzione il primo argomento è il programma chiamato
tmp[argc-1] = (char*)NULL; // come da manuale
for (i = argc-2; i > 0; i--) tmp[i] = argv[(argc-i)]; // inverto gli argomenti
execvp(tmp[0], tmp);
fprintf(stderr, "%s: command not found\n", argv[1]); //execvp ha fallito
return(EXIT_FAILURE);
}
</source>
--[[User:Ale|Ale]] ([[User talk:Ale|talk]]) 20:39, 1 December 2014 (CET)

==Esercizio 2==
===Soluzione di Dado e Pierg===
<source lang="text">
Scrivere un programma in linguaggio C che crei due named pipe (passate per argomento), le apra in lettura e
e copi in standard output i dati via via disponibili da ogni pipe.
Test di funzionamento: aprire tre finestre di emulazione terminale. Nella prima lanciare: mergepipe p1 p2, nella seconda:
cat >p1, nella terza cat>p2.
Tutto cio' che scriverete o nella seconda o nella terza finestra deve comparire nella prima.
</source>
<source lang="c">
#include <stdio.h>
#include <stdlib.h>
#include <poll.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

#define MAX 2048

int main (int argc, char *argv[]) {
if (argc < 3) {
perror("Argomenti sbagliati");
}
else {
struct pollfd pino [2];
nfds_t n = 2;
char buf[MAX];

mkfifo(argv[1], 0666);
mkfifo(argv[2], 0666);
pino[0].fd = open(argv[1], O_RDONLY | O_NONBLOCK);
pino[1].fd = open(argv[2], O_RDONLY | O_NONBLOCK);
pino[0].events = POLLIN;
pino[1].events = POLLIN;

while(1) {
int ret = poll(pino, n, 100);
if (ret == 1) {
if (pino[0].revents == POLLIN) {
ssize_t x = read(pino[0].fd, buf, MAX);
buf[x+1] = '\0';
printf("%s", buf);
pino[0].revents = 0;
}
else {
ssize_t x = read(pino[1].fd, buf, MAX);
buf[x+1] = '\0';
printf("%s", buf);
pino[1].revents = 0;
}
}
else if (ret == 2) {
ssize_t x = read(pino[0].fd, buf, MAX);
buf[x+1] = '\0';
printf("%s", buf);
pino[0].revents = 0;
x = read(pino[1].fd, buf, MAX);
buf[x+1] = '\0';
printf("%s", buf);
pino[1].revents = 0;
}
}
}
}
</source>

ProvaPratica 2013.09.13

2017-05-10T07:42:09Z

FedericoB: Aggiunte soluzione di un'altro studente

==Esercizio 1 e 2==
===Soluzione di Edu San===
<syntaxhighlight lang="C">

/***********************************************************************
* Prova Pratica di Laboratorio di Sistemi Operativi *
* 13 settembre 2013 *
* Esercizio 1+2 *
* *
* URL: http://www.cs.unibo.it/~renzo/so/pratiche/2013.09.13.pdf *
* Autore: Eduardo Santarelli *
************************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <dirent.h>
#include <unistd.h>

/* An entry in the hash table. */
typedef struct fileEntry{

const char *filename;
struct fileEntry *next;

} fileEntry;

/* Global variables */
fileEntry **table = NULL;
int table_size;

/* Hash function. Calculates XOR of 8-bytes blocks *
* (actually, sizeof(long int)) read from the input file */
unsigned int hash(const char *fname){

FILE *f;
unsigned long int hash_val = 0;
unsigned long int tmp = 0;

f = fopen(fname, "r");
fread(&hash_val, sizeof(unsigned long int), 1, f);

while((fread(&tmp, sizeof(unsigned long int), 1, f) == 1))
hash_val = hash_val^tmp;

fclose(f);
return hash_val;

}

/* Creates a table of struct fileEntry elements, based on the hash values of the files *
* detected by scandir. If a collision is detected, the new entry is pointed by the *
* 'next' field of the current last element*/
void populate_table(struct dirent *dir_list[], int n){

int i;

table_size = 2*n;
table = (fileEntry**)calloc(table_size, sizeof(fileEntry));
if(!table) abort();

for(i=0; i<n; i++){
unsigned int index;
fileEntry *entry = NULL;

entry = (fileEntry*)malloc(sizeof(fileEntry));
if(!entry) abort();

index = hash(dir_list[i]->d_name)%table_size;
if(table[index] == NULL){
entry->filename = dir_list[i]->d_name;
entry->next = NULL;
table[index] = entry;
}
else{
entry->filename = dir_list[i]->d_name;
entry->next = table[index];
table[index] = entry;
}
}

}

/* Compares two files */
int fcompare(const char *f1, const char *f2){

FILE *f, *g;
int file1, file2;

f = fopen(f1, "r");
g = fopen(f2, "r");

while(fread(&file1, sizeof(int), 1, f) && fread(&file2, sizeof(int), 1, g)){
if(file1!=file2){
fclose(f);
fclose(g);
return 0;
}
}
fclose(f);
fclose(g);
return 1;

}

/* This function scans the file table. If an entry contains more than one file, *
* it compares all them. If a duplicate is found, the first file is removed, *
* and a hard link is created with the deleted file's name, pointing to the *
* second, identical, file. */
void deduplicate(){

int i;

for(i=0; i<table_size; i++){
while(table[i] != NULL && table[i]->next != NULL){

fileEntry *file1, *file2;
file1 = table[i];
file2 = table[i]->next;
while(file2 != NULL){
if(fcompare(file1->filename, file2->filename)){
unlink(file1->filename);
link(file2->filename, file1->filename);
printf("%s -> %s\n", file1->filename, file2->filename);
break;
}
file2 = file2->next;
}
table[i] = table[i]->next;
}
}
}

/*selector function for scandir() */
int exclude(const struct dirent *dir){

if(dir->d_type != DT_REG)
return 0;
else
return 1;

}

int main(int argc, char *argv[]){

struct dirent **entries = NULL;
int num_files;

num_files = scandir(".", &entries, exclude, alphasort);

populate_table(entries, num_files);
deduplicate();

return EXIT_SUCCESS;

}
</syntaxhighlight>

===Soluzione di Maldus (ora con tabella hash!)===
<source lang="c">
#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <dirent.h>
#include <fcntl.h>
#include <stdlib.h>

#define SIZE 1024

char BUFF1[SIZE] ; /*buffer usati per leggere i file*/
char BUFF2[SIZE] ;

struct list{ /*struttura che uso per implementare la lista di file che hanno uguale somma crittografica*/
struct dirent* ent ;
struct list *next ;
struct list *prev ;
};

inline void del(struct list* p){ /*rimuove p dalla lista in cui si trova*/
(p->next)->prev = p->prev ;
(p->prev)->next = p->next ;
free(p) ;
}

int critsum( int f ){ /*somma crittografica per la tabella hash*/
int i , n ;
int x = 0 ;
while(( n = read( f , BUFF1 , SIZE ) )> 0 ){
for( i = 0 ; i < n ; i++ ){
x += ((int) BUFF1[i])*((i%8)+1) ; /*aggiungo ogni volta il valore numerico corrispondente al byte letto moltiplicato per un numero da 1 a 8*/
}
}
if( x < 0) return -x ;/*restituisco sempre un valore positivo, perchè possa essere usato come indice di un vettore*/
else return x ;
}

int buffcmp( char* buf1 , char* buf2 , int s1 , int s2 ){/*funzione che compara due buffer*/
int i ;
if( s1 != s2 ) return 1 ; /*se hanno lunghezza diversa sono diversi*/
for( i = 0 ; i < s1 ; i++ ){
if( buf1[i] != buf2[i] ) return 1 ;
}
return 0 ;
}

int filecmp( int f1 , int f2 ){ /*funzione ausiliaria che confronta due file. Si comporta come strcmp*/
int n1 , n2 ;
while(( n1 = read( f1 , BUFF1 , SIZE ) )> 0 ){ /*ho provato a inserire entrambe le read nel controllo del while con un &&; mi creava dei problemi, come se la seconda read venisse eseguita nel giro seguente del ciclo*/
n2 = read( f2 , BUFF2 , SIZE ) ;
if( buffcmp( BUFF1 , BUFF2 , n1 , n2 ) != 0 ) return 1 ; /*ritorna 1 se i due file sono diversi*/
}
return 0 ; /*ritorna 0 se sono uguali*/
}

void del_clones( struct list* p ){ /*cerca nella lista il cui primo elemento è p tutti i file con lo stesso contenuto*/
struct list *aux1 , *aux2 , *tmp;
int fd1, fd2 ;
struct stat s1 , s2 ;
aux1 = p ;
aux2 = aux1->next ;
while( aux1->next != p ){
printf( "%s:\n" , (aux1->ent)->d_name ) ;
if( stat( (aux1->ent)->d_name , &s1 ) != 0 ){
perror("stat") ;
exit(1) ;
}
if ( (fd1 = open((aux1->ent)->d_name, O_RDONLY ) ) == -1){ /*apro la entry*/
perror("open") ;
exit(1) ;
}

while( (aux2->next) != p && (aux2 != p) ){
tmp = aux2->next ;
if( stat( (aux2->ent)->d_name , &s2 ) != 0 ){
perror("stat") ;
exit(1) ;
}
if ( (fd2 = open((aux2->ent)->d_name, O_RDONLY ) ) == -1){ /*apro la entry*/
perror("open") ;
exit(1) ;
}
printf("\t%s" , (aux2->ent)->d_name) ;
if( s1.st_ino != s2.st_ino){
if( filecmp( fd1 , fd2 ) == 0 ){ /*controllo se i due file hanno lo stesso contenuto*/
printf("<-uguale\t") ;
unlink((aux2->ent)->d_name) ; /*rimuovo il file uguale*/
if( link( (aux1->ent)->d_name , (aux2->ent)->d_name) == -1 ){ /*creo un link fisico*/
perror("link") ;
exit(1) ;
}
del(aux2) ;
}
}
else del(aux2) ; /*se hanno lo stesso i-node toglili dalla lista*/
aux2 = tmp; /*tmp = aux2->next. Lo salvo in precedenza nel caso in cui aux2 sia stato cancellato*/
close(fd2) ;
}
printf("\n") ;
close(fd1) ;
aux1 = aux1->next ;

}
}

int main( int argc, char* argv[]){
struct stat s1 , s2; /*struttura di informazioni su un file*/
DIR *dir ; /*puntatore a directory*/
struct dirent *entry ; /*struttura di informazioni sulle entry di una directory*/
int fd1; /*descrittore di file*/
char *name ;
int n = 0 ; /*contatore di file all'interno della directory*/
int cs , i ; /*cs è somma crittografica del file*/
struct list *hash ;
struct list *tmp ;
if( stat( argv[1] , &s1 ) != 0 ){
perror("stat") ;
return 1 ;
}
if( !S_ISDIR(s1.st_mode) ){
printf( "argument is not a valid directory\n" ) ;
return 0 ;
}
if( (dir = opendir( argv[1] )) == NULL ){
perror("opendir") ;
return 1 ;
}
if( chdir( argv[1] ) == -1 ){ /*sposto la directory corrente in quella di esecuzione per poter aprire i file*/
perror("chdir") ;
return 1 ;
}
while( (entry = readdir(dir) ) != NULL){ /*conto i file contenuti nella directory*/
stat( entry->d_name , &s1 ) ;
if( S_ISREG(s1.st_mode) ) n++ ; /*se si tratta di un file normale contalo*/
}
printf("La directory contiene %i file\n" , n ) ;
n = 2*n ; /*da questo momento n è il numero di indici nella mia hashtable*/
hash = (struct list*) malloc( sizeof(struct list)*n) ; /*alloco una hash table con n = 2n indici*/
rewinddir(dir) ;
for( i = 0 ; i < n ; i++ ){ /*inizializzo le liste*/
hash[i].next = &hash[i] ;
hash[i].prev = &hash[i] ;
hash[i].ent = NULL ;
}
while( (entry = readdir(dir) ) != NULL){ /*con questo ciclo riempo la hashtable*/
stat( entry->d_name , &s1 ) ;
if( S_ISREG(s1.st_mode) ){ /*se si tratta di un file normale consideralo*/
if ( (fd1 = open(entry->d_name, O_RDONLY ) ) == -1){ /*apro la entry*/
perror("open") ;
exit(1) ;
}
cs = critsum( fd1 ) ;
tmp = (struct list*) malloc( sizeof(struct list) ) ;
tmp->ent = entry ;
(hash[cs%n].next)->prev = tmp ; /*inserisco il file in testa alla lista di indice cs%n*/
tmp->prev = &hash[cs%n] ;
tmp->next = hash[cs%n].next ;
hash[cs%n].next = tmp ;
close(fd1) ;
}
}
for( i = 0 ; i < n ; i++ ){ /*con questo ciclo cancello effettivamente i file uguali*/
printf("%i: " , i ) ;
if( hash[i].next != &hash[i] ){
del_clones( hash[i].next ) ;
}
else printf("\n") ;
}
return 0 ;
}
</source>

==Esercizio 3==
===Soluzione di Edu San===
<syntaxhighlight lang="Python">
#!/usr/bin/env python3

# Prova Pratica di Laboratorio di Sistemi Operativi
# 13 settembre 2013
# Esercizio 3
#
# URL: http://www.cs.unibo.it/~renzo/so/pratiche/2013.09.13.pdf *
# Autore: Eduardo Santarelli

class LineCounter:

def __init__(self, fileList):
# A list containing the char-per-line
# count for the specified files.
# Value for line 1 is in result[0] and so on.
self.result = []
self.files = fileList # List of files to elaborate.
self.getLinesCount()

# Count the chars for each lines of specified file,
# add the result to the relevant field in self.result,
# if already present, append the value to the
# end of the list if not.
def countLines(self, file):
i = 0
fd = open(file)
for line in fd:
lineLength = len(line)
# If an entry for the current line does
# not exist, append the value to the end of the list
try:
self.result[i] += lineLength
except IndexError:
self.result.append(lineLength)
i = i+1
fd.close()

# Call self.countLines() for each file in self.files
# in order to build the self.result list
def getLinesCount(self):
for entry in self.files:
self.countLines(entry)

# Print the items in self.result, each preceded by the
# corresponding line number.
def printLines(self):
i = 1
for value in self.result:
print("{:d}: {:d}".format(i, value))
i = i+1

import os

lc = LineCounter(os.listdir(os.getcwd()))
lc.printLines()
</syntaxhighlight>

===Soluzione di Pirata===
<syntaxhighlight lang="Bash">
#Esercizio 3: Script bash o Python: (10 punti):
#Sia data una directory che contiene file di testo.
#Scopo dell'esercizio e' di contare i caratteri delle corrispondenti righe di testo di tutti i file della directory, si vuole cioe' sapere
#il numero totale di caratteri presenti nelle prime righe di tutti i file, nelle seconde linee, ecc.
#$ ccpl mydir
#1 234
#2 21
#3 333
# .....
#l'ouput significa che se contiamo tutti i caratteri contenuti nella prima riga di tutti i file in mydir otteniamo 234 (mydir/file1
#puo' avere 40 caratteri nella prima riga, mydir/file2 ne puo' avere 20, ecc... procedendo per tutti i file di mydir la somma fa 234)

#! bin/bash

nline=1
touch fileresult
paste $1/* > fileresult #merges every file's line from the directory passed to the file fileresult
while read line; do
count=$(echo $line | wc -m) #counts the number of char in each line of fileresult
echo $nline $count
nline=$(($nline + 1))
done < fileresult
rm fileresult
</syntaxhighlight>

===Soluzione di Maldus===
<source lang="bash">
#! /bin/bash

count=1 #conta il numero di riga che sto considerando
bool=1 #resta 1 finchè ci sono righe da contare in qualche file
if [[ -n $1 ]]; then
cd $1
else
exit 1
fi
file=`ls`

while [[ $bool -eq 1 ]]; do
tot=0
bool=0
for word in $file; do
if [[ (-r $word) && (-s $word) && ( -f $word) && (! $word = *~ ) ]]; then
x=`awk 'NR==c' c=$count $word | wc -m` #considero solo la riga contata da count
if [[ $x -ne 0 ]]; then #se la riga non è vuota
tot=`expr $tot + $x - 1` #con -1 tolgo il carattere \n che era stato contato da awk
bool=1 #bool=1 finchè c'è qualche riga da contare
fi
fi
done
if [[ $bool -eq 1 ]]; then
echo "$count: $tot"
fi
count=`expr $count + 1`
done
</source>

===Soluzione di Davide Quadrelli===
<source lang="bash">
#!/bin/bash
if [[ -n $1 ]]; then
cd $1
files=`ls -p | grep -v /` #elenco file
else
echo"Inserire cartella come parametro"
exit
fi
array=()
#per ogni file nella cartella
for file in $files; do
i=0
while read line; do
#conto la lunghezza di ogni riga e la aggiungo nella corrispondente cella dell'array
len=`expr length "${line}"`
array[$i]=`expr ${array[$i]} + $len`
((i++))
done < $file
done
#a questo punto l'i-esima cella contiene la somma delle lunghezze della i-esima riga di ogni file
i=1
for n in ${array[@]}; do
echo "$i $n"
((i++))
done
</source>