Sistemi Operativi - User contributions [en]

ProvaTeorica 2013.01.24

2017-07-08T09:32:45Z

Mak: /* Esercizio g1 */

testo: http://www.cs.unibo.it/~renzo/so/compiti/2013-01-24.tot.pdf

Esercizio C1:
(a) Scrivere un monitor nmbb che realizzi un buffer limitato (di ampiezza BUFSIZE) che consenta alle
chiamate write (inserimento nel buffer) e read (lettura da buffer) di operare su vettori di piu' elementi. In particolare
l'interfaccia delle procedure entry da implementare e' la seguente:
procedure entry write(int n, struct elem *v);
procedure entry read(int m, struct elem *w);
se n o m sono maggiori di BUFSIZE le funzioni non devono fare nulla (caso di errore).
La funzione write deve attendere che ci sia spazio nel buffer per inserire n elementi (il vettore v conterra' n elementi).
Solo quando e' possibile completare l'operazione vengono inseriti tutti gli elementi di v nel buffer.
La funzione read attende che vi siano almeno m elementi nel buffer quindi estrae dal buffer (in ordine FIFO) m elementi e li copia nel vettore w .
(b) sono possibili casi di deadlock? (motivare dettagliatamente la risposta)

La mia Soluzione:
<syntaxhighlight lang="C">
read(): legge dalla coda un elemento senza rimuoverlo
queue(elem v,int n): inserisce nella coda n elementi v;
dequeue(int n): legge n elementi dalla coda e li rimuove;

monitor mnbb{
conditon oktowrite, oktoread;
queue qwrite,qread;

procedure entry write(int n, struct elem *v){
if(n > BUFSIZE){
return(ERROR);
}
if( n > (BUFSIZE - buff.lengh)){
qwrite.queue( n, 1 );
oktowrite.wait();
}
buff.queue( v, n );
if(qread.read() <= buff.lengh){
qread.dequeue(1);
oktoread.signal();
}
}

procedure entry read(int m, struct elem *w){
if(m > BUFSIZE){
return(ERROR);
}
if(m > buff.lengh){
qread.queue( m, 1 );
oktoread.wait();
}
w = buff.dequeue(m);
if(qwrite.read() <= (BUFSIZE - buff.lengh)){
qwrite.dequeue(1);
oktowirte.signal();
}
}
}
</syntaxhighlight>
- Midolo

----

<syntaxhighlight lang="C">
monitor nmbb{
queue buffer;
condition oktowrite;
condition oktoread;

/* assumiamo che essendo un buffer limitato ci sia un solo processo che vuole scrivere e un solo processo che vuole leggere */
int N, M;

procedure entry write(int n, struct elem *v){
if(n>BUFSIZE) return;
N=n;
if((BUFSIZE - buffer.len) < N)
oktowrite.wait();

for(i=0; i<N; i++)
buffer.enqueue(v[i]);

if(buffer.len >= M)
oktoread.signal();
}

procedure entry read(int m, struct elem *w){
if(m>BUFSIZE) return;
M=m;
if((BUFSIZE - buffer.len) < M)
oktoread.wait();

for(i=0; i<M; i++)
w[i] = buffer.dequeue;

if((BUFSIZE - buffer.len) >= N)
oktowrite.signal();
}
}
</syntaxhighlight>
Si può verificare deadlock. Esempio: un lettore vuole leggere un tot di elementi, ma quelli presenti non sono sufficienti. Uno scrittore a sua volta non può più scrivere un certo numero di elementi in quanto il buffer è parzialmente occupato. Lo scrittore aspetterà che il lettore legga; il lettore aspetterà invece lo scrittore: deadlock.

L'eventualità che si verifichi deadlock tuttavia è contemplata dalla traccia, come fa capire il punto b)

Gabriele e Giulia

== Esercizio g1 ==

{| border="1"
|-
|TEMPO
|1
|2
|3
|4
|5
|6
|7
|8
|9
|10
|11
|12
|13
|14
|15
|16
|17
|18
|19
|20
|21
|22
|23
|24
|-
|CPU 1
|P1
|P1
|P1
|P4
|P4
|P4
|P3
|P2
|P2
| 
| 
|P1
|P1
| 
|P3
|P3
|P3
|P4
| 
|P1
|P1
|P1
|P1
|P1
|-
|CPU 2
|P2
|P2
|P3
|P3
|P3
|P1
|P1
|P4
|P4
|P4
|P4
|P4
|P4
|P4
|P4
|P4
|P2
|P2
|P2
|P2
|P2
|P3
|P3
|P3
|-
|I/O
| 
| 
|P2
|P2
|P2
|P2
| 
|P1
|P1
|P1
|P1
|P3
|P3
|P3
|P2
|P1
|P1
|P1
|P1
|P3
|P3
|P4
| 
| 
|}

GiuliaN.

Mak

SMP |1|1|1|4|4|4|3|2|2| | |1|1| |3|3|3|4| |1|1|1|1|1|
|2|2|3|3|3|1|1|4|4|4|4|4|4|4|4|4|2|2|2|2|2|3|3|3|
RQ |3|3| |1|1|3|2| | | | | | | | | | | | | | | | | |
|4|4|4| | | |4| | | | | | | |3|2|4| | | | | | | |
IO | | |2|2|2|2| |1|1|1|1|3|3|3|2|1|1|1|1|3|3|4| | |

Prova Teorica 2013.06.21

2017-07-07T16:02:14Z

Mak:

<h1>[http://www.cs.unibo.it/~renzo/so/compiti/2013.06.21.tot.pdf Testo del compito]</h1>

<h2> Esercizio c.1 </h2>

<syntaxhighlight lang="C">

monitor nvie
{
condition oktoread;
queue buffer[N];

procedure entry put(int n, generic object)
{

if (buffer[n].length < NELEM)
buffer[n].enqueue(object);

oktoread.signal();

}

procedure entry generic get(generic *object)
{

int count=0;

for (int i=0;i<N;i++)
{
if (buffer[i].length>0)
count++;
return None ;
}
for (int j=0;j<N;j++)
{ if (count>=N/2)
(buffer[j].dequeue(*object) ;
oktoread.wait();
}
}
}

Save
</syntaxhighlight>

<h2> Esercizio g.1 </h2>
[[http://so.v2.cs.unibo.it/wiki/images/0/02/G1paginazione.jpg soluzione]]

<h2> Esercizio g.1 </h2>

P1 2 2 2 2 2
P2 3 2 3 2 3
P3 1 2 1 2 1

NON-PREEMPTIVE

CPU |1|1|2|2|2|1|1|2|2|2|1|1|2|2|2|3| | |3| | |3|
RQ |2|2|1|1|1|2|2|1|1|1|2|2|3|3|3| | | | | | | |
|3|3|3|3|3|3|3|3|3|3|3|3| | | | | | | | | | |
IO1 | | |1|1| | | |1|1| | | | | | | | | | | | | |
IO2 | | | | | |2|2| | | |2|2| | | | | | | | | | |
IO3 | | | | | | | | | | | | | | | | |3|3| |3|3| |

PREEMPTIVE

CPU |1|1|2|2|1|1|2|3|1|1|2|2|2|3|2|2|2|3|
RQ |2|2| | |2|2| | | |2|3|3|3| | | |3| |
|3|3|3|3|3|3|3| | | | | | | | | | | |
IO1 | | |1|1| | |1|1| | | | | | | | | | |
IO2 | | | | | | | |2|2| | | | |2|2| | | |
IO3 | | | | | | | | |3|3| | | | |3|3| | |

<h2> Esercizio g.2 </h2>

a) quali sono le differenze fra la paginazione e la segmentazione nella gestione della memoria?

PAGINAZIONE
Dimensioni pagina fissa; suddivisione automatica; le pagine possono contenere informazioni disomogenee (codice, dati); una pagina ha un indirizzo; dim tipiche: 1-4KB

SEGMENTAZIONE
Dimensioni variabili; la suddivisione in segmenti e' compito del programmatore; i segmenti contengono dati omogenei; un segmento ha un nome; dim tipica: 64KB-1MB

b) quali sono le differenze fra le operazioni P e V dei semafori e le operazioni wait/signal delle variabili di condizione?

Signal() non ha alcun effetto se nessun processo sta attendendo la condizione. V memorizza il verificarsi degli eventi.
Wait() e' sempre bloccante. P, se il semaforo ha valore positivo, no.
Il processo risvegliato dalla signal viene eseguito per primo.

c) allocazione contigua, concatenata e indicizzata nei file system, quali sono le differenze e i campi di applicazione?

Nell'allocazione contigua ogni file viene allocato in blocchi di memoria adiacenti.

PRO: non sono presenti strutture di collegamento, l'accesso sequenziale è efficiente. Anche l'accesso diretto risulta efficiente.

CON: frammentazione esterna, politica scelta blocchi liberi da usare; i file non possono crescere

APP: e'utilizzato nell'ISO 9660 (dischi ottici) e nel file system NTFS.

Nell'allocazione concatenata ogni file è una lista concatenata di blocchi ed ogni blocco contiene un puntatore al blocco successivo.

PRO: accesso sequenziale o in append mode efficiente, risolve la frammentazione esterna

CON: l'accesso diretto è inefficiente, se il blocco è piccolo l'overhead per i puntatori può essere rilevante.

APP: utile per i log, dato l'accesso efficiente in append mode. Usata in Xerox alto, DEC TOPS-10

Nell'allocazione indicizzata l'elenco dei blocchi che compongono un file viene memorizzato in un'area indice, quindi per accedere ad un file si carica in memoria la sua area indice e si utilizzano i puntatori contenuti.

PRO: risolve frammentazione esterna; efficiente per accesso diretto. Il blocco indice viene caricato in memoria solo quando il file è aperto.

CON: la dimensinoe del blocco indice determina ampiezza massima file

APP: file grosse dimensioni in quanto e' facile accedere alla parte intermedia del file. Utile per i file system di uso generale.

<h2> Esercizio c.2 </h2>
<syntaxhighlight lang="C">

#Casi possibili delle iterazioni
int val = 0

PQPQQ (((val +1) *2) +1) * 2 * 2 → 12
PQQPQ (( val +1 ) * 2 * 2) +1 * 2 → 12
QQPQP (((val * 2 * 2) + 1 )* 2) + 1 → 3
QPQQP (((val * 2) + 1) * 2 * 2) + 1 → 5
QPQPQ ((((val * 2) + 1) * 2) + 1) * 2 → 6

a) #Quindi i valori possibili sono → (3, 5, 6, 12)
b) #

</syntaxhighlight>
- Midolo e Marangoni

Prova Teorica 2013.06.21

2017-07-07T16:00:34Z

Mak:

<h1>[http://www.cs.unibo.it/~renzo/so/compiti/2013.06.21.tot.pdf Testo del compito]</h1>

<h2> Esercizio c.1 </h2>

<syntaxhighlight lang="C">

monitor nvie
{
condition oktoread;
queue buffer[N];

procedure entry put(int n, generic object)
{

if (buffer[n].length < NELEM)
buffer[n].enqueue(object);

oktoread.signal();

}

procedure entry generic get(generic *object)
{

int count=0;

for (int i=0;i<N;i++)
{
if (buffer[i].length>0)
count++;
return None ;
}
for (int j=0;j<N;j++)
{ if (count>=N/2)
(buffer[j].dequeue(*object) ;
oktoread.wait();
}
}
}

Save
</syntaxhighlight>

<h2> Esercizio g.1 </h2>
[[http://so.v2.cs.unibo.it/wiki/images/0/02/G1paginazione.jpg soluzione]]

<h2> Esercizio g.1 </h2>

P1 2 2 2 2 2
P2 3 2 3 2 3
P3 1 2 1 2 1

NON-PREEMPTIVE

CPU |1|1|2|2|2|1|1|2|2|2|1|1|2|2|2|3| | |3| | |3|
RQ |2|2|1|1|1|2|2|1|1|1|2|2|3|3|3| | | | | | | |
|3|3|3|3|3|3|3|3|3|3|3|3| | | | | | | | | | |
IO1 | | |1|1| | | |1|1| | | | | | | | | | | | | |
IO2 | | | | | |2|2| | | |2|2| | | | | | | | | | |
IO3 | | | | | | | | | | | | | | | | |3|3| |3|3| |

PREEMPTIVE

CPU |1|1|2|2|1|1|2|3|1|1|2|2|2|3|2|2|2|3|
RQ |2|2| | |2|2| | | |2|3|3|3| | | |3| |
|3|3|3|3|3|3|3| | | | | | | | | | | |
IO1 | | |1|1| | |1|1| | | | | | | | | | |
IO2 | | | | | | | |2|2| | | | |2|2| | | |
IO3 | | | | | | | | |3|3| | | | |3|3| | |

<h2> Esercizio g.2 </h2>

a) quali sono le differenze fra la paginazione e la segmentazione nella gestione della memoria?

PAGINAZIONE
Dimensioni pagina fissa
Suddivisione automatica
Le pagine possono contenere informazioni disomogenee (codice, dati)
Una pagina ha un indirizzo
Dim tipiche: 1-4KB

SEGMENTAZIONE
Dimensioni variabili
La suddivisione in segmenti e' compito del programmatore
I segmenti contengono dati omogenei
Un segmento ha un nome
Dim tipica: 64KB-1MB

b) quali sono le differenze fra le operazioni P e V dei semafori e le operazioni wait/signal delle variabili di condizione?

Signal() non ha alcun effetto se nessun processo sta attendendo la condizione. V memorizza il verificarsi degli eventi.
Wait() e' sempre bloccante. P, se il semaforo ha valore positivo, no.
Il processo risvegliato dalla signal viene eseguito per primo.

c) allocazione contigua, concatenata e indicizzata nei file system, quali sono le differenze e i campi di applicazione?

Nell'allocazione contigua ogni file viene allocato in blocchi di memoria adiacenti.

PRO: non sono presenti strutture di collegamento, l'accesso sequenziale è efficiente. Anche l'accesso diretto risulta efficiente.

CON: frammentazione esterna, politica scelta blocchi liberi da usare; i file non possono crescere

APP: e'utilizzato nell'ISO 9660 (dischi ottici) e nel file system NTFS.

Nell'allocazione concatenata ogni file è una lista concatenata di blocchi ed ogni blocco contiene un puntatore al blocco successivo.

PRO: accesso sequenziale o in append mode efficiente, risolve la frammentazione esterna

CON: l'accesso diretto è inefficiente, se il blocco è piccolo l'overhead per i puntatori può essere rilevante.

APP: utile per i log, dato l'accesso efficiente in append mode. Usata in Xerox alto, DEC TOPS-10

Nell'allocazione indicizzata l'elenco dei blocchi che compongono un file viene memorizzato in un'area indice, quindi per accedere ad un file si carica in memoria la sua area indice e si utilizzano i puntatori contenuti.

PRO: risolve frammentazione esterna; efficiente per accesso diretto. Il blocco indice viene caricato in memoria solo quando il file è aperto.

CON: la dimensinoe del blocco indice determina ampiezza massima file

APP: file grosse dimensioni in quanto e' facile accedere alla parte intermedia del file. Utile per i file system di uso generale.

<h2> Esercizio c.2 </h2>
<syntaxhighlight lang="C">

#Casi possibili delle iterazioni
int val = 0

PQPQQ (((val +1) *2) +1) * 2 * 2 → 12
PQQPQ (( val +1 ) * 2 * 2) +1 * 2 → 12
QQPQP (((val * 2 * 2) + 1 )* 2) + 1 → 3
QPQQP (((val * 2) + 1) * 2 * 2) + 1 → 5
QPQPQ ((((val * 2) + 1) * 2) + 1) * 2 → 6

a) #Quindi i valori possibili sono → (3, 5, 6, 12)
b) #

</syntaxhighlight>
- Midolo e Marangoni

Prova Teorica 2013.09.12

2017-07-05T09:53:49Z

Mak: /* Esercizio g.2 */

<h1>[http://www.cs.unibo.it/~renzo/so/compiti/2013.09.12.tot.pdf Testo del compito]</h1>
== Esercizio g.2 ==

Q: Il meccanismo RAID livello 0 aumenta la tolleranza ai guasti.
A: FALSO

RAID 0 sebbene utilizzi l'acronimo RAID, in realtà non presenta meccanismi
di ridondanza.
I dati infatti sono suddivisi in strip consecutivi su dischi diversi,
aumentando le performance di lettura di dati sequenziali.
E' più indicato per applicazioni nelle quali l'affidabilità
non è un grosso problema.

Q: I microkernel consentono maggiori performance rispetto ai kernel
monolitici
A: FALSO

C'è un overhead dovuto alla comunicazione mediata tramite kernel
del sistema operativo, anche se parzialmente superata con i s.o. recenti.
La comunicazione ha un overhead perchè è basata su message passing.

Q: L'uso di librerie dinamiche consente una minor occupazione di memoria
principale e secondaria.
A: VERO

Mentre nel linking statico le routine di libreria vengono copiate in OGNI
programma che le usa (es: printf), con il linking dinamico le librerie
vengono implementate come codice reentrant, ovvero ne è presente una sola
istanza in memoria e tutti i programmi eseguono il codice di questa istanza.

Q: Esistono stringhe di riferimenti per le quali LRU e MIN causano lo stesso numero di page fault.
A: VERO

LRU

0 1 2 3 4 1 2 3 0 2 3 0 1 3 0 1
0 0 0 0 4 4 4 4 4 4 4 4 4 4 4 4
1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
2 2 2 2 2 2 2 2 2 2 2 1 1 1
3 3 3 3 3 3 3 3 3 3 3 3 3
^ ^ ^ 3PF
MIN

0 1 2 3 4 1 2 3 0 2 3 0 1 3 0 1
0 0 0 0 4 4 4 4 4 4 4 4 4 4 4 4
1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
2 2 2 2 2 2 2 2 2 2 1 1 1 1
3 3 3 3 3 3 3 3 3 3 3 3 3
^ ^ ^ 3PF

== Esercizio c.2 ==

[[File:Esemafori.png]]

by Mario

Prova Teorica 2013.09.12

2017-07-05T09:51:01Z

Mak: /* Esercizio c.2 */

<h1>[http://www.cs.unibo.it/~renzo/so/compiti/2013.09.12.tot.pdf Testo del compito]</h1>
== Esercizio g.2 ==

Q: Il meccanismo RAID livello 0 aumenta la tolleranza ai guasti.
A: F

RAID 0 sebbene utilizzi l'acronimo RAID, in realtà non presenta meccanismi
di ridondanza.
I dati infatti sono suddivisi in strip consecutivi su dischi diversi,
aumentando le performance di lettura di dati sequenziali.
E' più indicato per applicazioni nelle quali l'affidabilità
non è un grosso problema.

Q: I microkernel consentono maggiori performance rispetto ai kernel
monolitici
A: F

C'è un overhead dovuto alla comunicazione mediata tramite kernel
del sistema operativo, anche se parzialmente superata con i s.o. recenti.
La comunicazione ha un overhead perchè è basata su message passing.

Q: L'uso di librerie dinamiche consente una minor occupazione di memoria
principale e secondaria.
A: V

Mentre nel linking statico le routine di libreria vengono copiate in OGNI
programma che le usa (es: printf), con il linking dinamico le librerie
vengono implementate come codice reentrant, ovvero ne è presente una sola
istanza in memoria e tutti i programmi eseguono il codice di questa istanza.

Q: Esistono stringhe di riferimenti per le quali LRU e MIN causano lo stesso
numero di page fault.
A: v

LRU

0 1 2 3 4 1 2 3 0 2 3 0 1 3 0 1
0 0 0 0 4 4 4 4 4 4 4 4 4 4 4 4
1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
2 2 2 2 2 2 2 2 2 2 2 1 1 1
3 3 3 3 3 3 3 3 3 3 3 3 3
^ ^ ^ 3PF
MIN

0 1 2 3 4 1 2 3 0 2 3 0 1 3 0 1
0 0 0 0 4 4 4 4 4 4 4 4 4 4 4 4
1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
2 2 2 2 2 2 2 2 2 2 1 1 1 1
3 3 3 3 3 3 3 3 3 3 3 3 3
^ ^ ^ 3PF

== Esercizio c.2 ==

[[File:Esemafori.png]]

by Mario

ProvaTeoria 2012.01.12

2017-06-23T16:42:45Z

Mak: /* Esercizio 2 */

=[http://www.cs.unibo.it/~renzo/so/compiti/2012-01-12.tot.pdf TESTO COMPITO]=

== Esercizio 1 ==
P1: 5 6 2 4 5
P2: 2 4 2 2 5
P3: 4 3 3 2 3
C I C I C

P1 ready queue

SMP|2|2|1|1|1|1|1| | |3|3|3| | | |1|1| | | | | | |1|1|1|1|1| 28 ms
|3|3|3|3| |2|2| | | | | | | | | | | | | | | | | | | | | |
RQ |1| | | | | | | | | | | | | | | | | | | | | | | | | | | |
I/O| | |2|2|2|2|3|3|3|1|1|1|1|1|1|2|2|3|3|1|1|1|1| | | | | |

P2 ready queue

SMP|1|1|1|1|1| | | | | | | | | | | | | | | | | | | | |2|2|2|2|2| 30ms
|3|3|3|3|2|2| |3|3|3| | | |1|1| | |2|2|3|3|3| |1|1|1|1|1| | |
RQ |2|2|2|2| | | | | | | | | | | | | | | | | | | | | | | | | | |
I/O| | | | |3|3|3|1|1|1|1|1|1|2|2|2|2|3|3|1|1|1|1|2|2|2| | | | |

P3 ready queue

SMP|1|1|1|1|1||2|2|| | | |1|1| |3|3|3| | | |1|1|1|1|1| 26ms
|2|2|3|3|3|3| | | | | | | | | | |2|2|2|2|2| |3|3|3|
RQ |3| | | | | | | | | | | | | | | | | | | | | | | | |
I/O| | |2|2|2|2|1|1|1|1|1|1|3|3|3|2|2|1|1|1|1|3|3| | |

== Esercizio 2 ==

MIN

0 1 2 3 4 5 6 0 1 2 3 4 5 0 1 2 3 4 6 0 1 2

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 1 1 1 1 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 2 2 2 2 2
3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
5 6 6 6 6 6 6 5 5 5 5 5 5 6 6 6 6
^ ^ ^ 3 PF

FIFO

0 1 2 3 4 5 6 0 1 2 3 4 5 0 1 2 3 4 6 0 1 2

0 0 0 0 0 0 6 6 6 6 6 6 5 5 5 5 5 5 5 5 5 5
1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 6 6 6 6
2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 0 0
3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 2 1 1
4 4 4 4 4 4 3 3 3 3 3 3 3 3 3 3 3 2
5 5 5 5 5 5 4 4 4 4 4 4 4 4 4 4 4
^ ^ ^ ^ ^ ^ ^ ^ ^ 9 PF

==Esercizio 1==

<syntaxhighlight lang="C">
struct proc{
int id;
condition oktoexit;
};

monitor seq{
stack of struct proc inside; /*pila di proc*/

procedure entry enter(){
this=malloc(sizeof(struct proc)); //or this=new(struct proc);
this->id = getpid();
inside.push(this);
}

procedure entry exit(){
struct proc *mine = inside.search(getpid()); //cerca il mio elemento nella pila
if(inside.first()!= mine) /*first restituisce il primo elemento in cima alla pila*/
mine->oktoexit.wait(); /*se l'elemento corrente non è il primo nella pila, allora deve aspettare*/
inside.pop(); /*rimuovo l'elemento corrente dalla pila*/
free(mine); //butto via il risultato perché è certamente == mine
next=inside.first();
inside.first()->oktoexit.signal(); /*risvegliamo il primo elemento sulla pila*/
}
}
</syntaxhighlight>

GiuliaN. (con le correzioni del professore)

----

<syntaxhighlight lang="C">
monitor seq
{
condition* c=List() /*lista di condizioni, una per ogni processo arrivato*/
int* procstack=Stack(); /*stack di processi per l'uscita LIFO*/

procedure entry enter()
{
procstack.push(this->p_id);
}

procedure entry exit()
{
if (procstack.Top()!=this->p_id){ /*cioè se il processo non è in cima allo stack*/
List.insert(this->p_id);
(List.search(this->p_id)).wait(); /*aggiungo il mio p_id alla lista di condizioni e mi metto in wait*/
}
List.remove(this->p_id);
procstack.Pop();
List.search(procstack.Top()).signal();
}
}
</syntaxhighlight>

NOTA: Con questa soluzione se l'ultimo processo chiama la exit e ci sono altri processi in coda, gli altri processi usciranno prima che l'ultimo esca dallo urgent stack per uscire a sua volta, quindi non credo che rispetti la traccia.
Però non ho trovato un'altra soluzione

==Esercizio 2==
<syntaxhighlight lang="C">
pid index[N] /*index contiene gli id dei vari server*/

process server[0]
{
while(1)
{
tmp msg=arecv(*);
for (i=1;i<N;i++)
asend(index[i],tmp);
print(tmp);
}
}

process server[1...N-1]
{
while(1)
{
msg tmp =arecv(*)
if (tmp.sender==index[0])
print(tmp);
else
asend(index[0],tmp);
}
}

</syntaxhighlight>
-stefano92

----

<syntaxhighlight lang="C">

process server[0]{ //il primo processo server, che gestisce tutti gli altri
while(1){
(sender, m) = areceive(*);
//chiunque mi abbia spedito il msg io lo stampo
printf(m);
//lo mando a tutti gli altri server (me escluso) in modo che lo stampino
for(i=1; i<N; i++)
asend((server0, m), server[i]);
}
}

process server[i]{ //per i che va da 1 a N, dove lo 0-esimo è il primo server
while(1){
(sender, m) = areceive(*);
if(sender == server0)
printf(m);
else //messaggio dal client
asend(m, server0); //lo mando al server0, senza prima stamparlo
}
}
</syntaxhighlight>
GiuliaN.

ProvaTeoria 2012.01.12

2017-06-23T16:40:01Z

Mak: /* Esercizio 2 */

=[http://www.cs.unibo.it/~renzo/so/compiti/2012-01-12.tot.pdf TESTO COMPITO]=

== Esercizio 2 ==

MIN

0 1 2 3 4 5 6 0 1 2 3 4 5 0 1 2 3 4 6 0 1 2

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 1 1 1 1 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 2 2 2 2 2
3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
5 6 6 6 6 6 6 5 5 5 5 5 5 6 6 6 6
^ ^ ^ 3 PF

FIFO

0 1 2 3 4 5 6 0 1 2 3 4 5 0 1 2 3 4 6 0 1 2

0 0 0 0 0 0 6 6 6 6 6 6 5 5 5 5 5 5 5 5 5 5
1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 6 6 6 6
2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 1 0 0 0
3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 2 1 1
4 4 4 4 4 4 3 3 3 3 3 3 3 3 3 3 3 2
5 5 5 5 5 5 4 4 4 4 4 4 4 4 4 4 4
^ ^ ^ ^ ^ ^ ^ ^ ^ 9 PF

==Esercizio 1==

<syntaxhighlight lang="C">
struct proc{
int id;
condition oktoexit;
};

monitor seq{
stack of struct proc inside; /*pila di proc*/

procedure entry enter(){
this=malloc(sizeof(struct proc)); //or this=new(struct proc);
this->id = getpid();
inside.push(this);
}

procedure entry exit(){
struct proc *mine = inside.search(getpid()); //cerca il mio elemento nella pila
if(inside.first()!= mine) /*first restituisce il primo elemento in cima alla pila*/
mine->oktoexit.wait(); /*se l'elemento corrente non è il primo nella pila, allora deve aspettare*/
inside.pop(); /*rimuovo l'elemento corrente dalla pila*/
free(mine); //butto via il risultato perché è certamente == mine
next=inside.first();
inside.first()->oktoexit.signal(); /*risvegliamo il primo elemento sulla pila*/
}
}
</syntaxhighlight>

GiuliaN. (con le correzioni del professore)

----

<syntaxhighlight lang="C">
monitor seq
{
condition* c=List() /*lista di condizioni, una per ogni processo arrivato*/
int* procstack=Stack(); /*stack di processi per l'uscita LIFO*/

procedure entry enter()
{
procstack.push(this->p_id);
}

procedure entry exit()
{
if (procstack.Top()!=this->p_id){ /*cioè se il processo non è in cima allo stack*/
List.insert(this->p_id);
(List.search(this->p_id)).wait(); /*aggiungo il mio p_id alla lista di condizioni e mi metto in wait*/
}
List.remove(this->p_id);
procstack.Pop();
List.search(procstack.Top()).signal();
}
}
</syntaxhighlight>

NOTA: Con questa soluzione se l'ultimo processo chiama la exit e ci sono altri processi in coda, gli altri processi usciranno prima che l'ultimo esca dallo urgent stack per uscire a sua volta, quindi non credo che rispetti la traccia.
Però non ho trovato un'altra soluzione

==Esercizio 2==
<syntaxhighlight lang="C">
pid index[N] /*index contiene gli id dei vari server*/

process server[0]
{
while(1)
{
tmp msg=arecv(*);
for (i=1;i<N;i++)
asend(index[i],tmp);
print(tmp);
}
}

process server[1...N-1]
{
while(1)
{
msg tmp =arecv(*)
if (tmp.sender==index[0])
print(tmp);
else
asend(index[0],tmp);
}
}

</syntaxhighlight>
-stefano92

----

<syntaxhighlight lang="C">

process server[0]{ //il primo processo server, che gestisce tutti gli altri
while(1){
(sender, m) = areceive(*);
//chiunque mi abbia spedito il msg io lo stampo
printf(m);
//lo mando a tutti gli altri server (me escluso) in modo che lo stampino
for(i=1; i<N; i++)
asend((server0, m), server[i]);
}
}

process server[i]{ //per i che va da 1 a N, dove lo 0-esimo è il primo server
while(1){
(sender, m) = areceive(*);
if(sender == server0)
printf(m);
else //messaggio dal client
asend(m, server0); //lo mando al server0, senza prima stamparlo
}
}
</syntaxhighlight>
GiuliaN.

ProvaTeoria 2012.01.12

2017-06-23T16:39:09Z

Mak: /* Esercizio 1 */

ProvaTeorica 2014.01.22

2017-06-16T14:24:43Z

Mak: /* Esercizio g.1 */

<h1>[http://www.cs.unibo.it/~renzo/so/compiti/2014.01.22.tot.pdf Testo del compito]</h1>

<syntaxhighlight lang="C">

URL: http://www.cs.unibo.it/~renzo/so/compiti/2014.01.22.tot.pdf

@author: Alessandro

monitor bridge {
condition oktomove; /* auto attraversa il ponte */
int turn=0; /*indica il senso delle auto */
int est=0,ovest=0; /*contatori delle auto da est e da ovest */
Queue q; /*coda delle senso delle macchine in attesa */

procedure entry enter (char EoW)
{
if(EoW == "E") /* viene da est */
{
if(turn == 2 || est >=N || !empty(q))
{
q=enqueue("E"); /*inserisco nella coda dei sensi*/
oktomove.wait(); /*aspetta*/

}
turn = 1; /*impongo il senso delle auto in circolo nel ponte */
est++;
}
else /* viene da ovest */
{
if(turn ==1 || ovest >=N || !empty(q))
{
q=enqueue("O"); /*inserisco nella coda dei sensi*/
oktomove.wait(); /*aspetta*/

}
turn = 2; /*impongo il senso delle auto in circolo nel ponte */
ovest++;
}
}

procedure entry exit(char EoW)
{
char r;
if(EoW == "O")
{
est--;
r=head(q); /* leggo la prossima auto che aspetta di entrare */
if(est == 0 || r == "E") /*nessuna auto in transito nel ponte o il prossimo va nella stessa direzione*/
{
est--;
if(est == 0) /*nessuna auto in transito nel ponte */
{
turn = 0; /*avanti un altro */
}
if(!empty(q))
{
q.dequeue();
oktomove.signal(); /*segnale*/
}
}
else
{
ovest--;
r=head(q); /* leggo la prossima auto che aspetta di entrare */
if(ovest == 0 || r == "O") /*nessuna auto in transito nel ponte o il prossimo va nella stessa direzione*/
{
turn = 0; /*avanti un altro */
}
if(!empty(q))
{
q.dequeue();
oktomove.signal(); /*segnale*/
}
}
}

}
</syntaxhighlight>

------

<syntaxhighlight lang="C">
/*
* URL: http://www.cs.unibo.it/~renzo/so/compiti/2014.01.22.tot.pdf
* author: Tommaso Ognibene
*/

monitor bridge
{
condition okE; // attraversare in direzione Est
condition okW; // attraversare in direzione Ovest
int n = 0; // numero di veicoli sul ponte
int waitingE = 0; // numero di veicoli che attendono di attraversare in direzione Est
int waitingW = 0; // numero di veicoli che attendono di attraversare in direzione Ovest
bool toE = true; // direzione di attraversamento

procedure entry enter(Vehicle vehicle)
{
// [Case 1] Il veicolo vuole attraversare in direzione Ovest
if (vehicle.To == 'W')
{
/* Se - il numero di veicoli sul ponte ha raggiunto il massimo; oppure
- qualcuno sta attraversando in direzione opposta; oppure
- qualcuno sta attendendo di attraversare in direzione opposta */
if (n == N || (toE && n > 0) || (!toE && waitingE > 0))
{
// Mi fermo e attendo di essere sbloccato
waitingW++;
okW.wait();
waitingW--;
}
toE = false;
n++;

/* Se possibile, sblocco eventuali altri veicoli in attesa per la stessa direzione.
* Questo non crea starvation in quanto sono sicuramente un numero limitato. */
if (n < N && waitingE == 0)
okW.signal();
}
// [Case 2] Il veicolo vuole attraversare in direzione Est
else
{
/* Se - il numero di veicoli sul ponte ha raggiunto il massimo; oppure
- qualcuno sta attraversando in direzione opposta; oppure
- qualcuno sta attendendo di attraversare in direzione opposta */
if (n == N || (!toE && n > 0) || (toE && waitingW > 0))
{
// Mi fermo e attendo di essere sbloccato
waitingE++;
okE.wait();
waitingE--;
}
toE = true;
n++;

/* Se possibile, sblocco eventuali altri veicoli in attesa per la stessa direzione.
* Questo non crea starvation in quanto sono sicuramente un numero limitato. */
if (n < N && waitingW == 0)
okE.signal();
}
}

procedure entry exit(Vehicle vehicle)
{
n--;
/* Se nessuno sta attraversando il ponte */
if (n == 0)
{
// [Case 1] L'ultimo ad attraversare andava in direzione Ovest
if (vehicle.To == 'W')
{
/* Se esiste, attivo il veicolo che per primo si era messo
in attesa per la direzione opposta */
if (waitingE > 0)
okE.signal();
else
okW.signal();
}
// [Case 2] L'ultimo ad attraversare andava in direzione Est
else
{
/* Se esiste, attivo il veicolo che per primo si era messo
in attesa per la direzione opposta */
if (waitingW > 0)
okW.signal();
else
okE.signal();
}
}
}
}
</syntaxhighlight>

La Mia soluzione:
<syntaxhighlight lang="C">
/*
* author: Midolo
*/

Monitor Ponte {
#define O 0
#define E 1
condition oktocross[2];
int countwaiting[2], crossing;

bridge.enter(dir){
if(crossing != 0 || countwaiting[1-dir] != 0){
countwaiting[dir]++;
oktocross[dir].wait();
countwaiting[dir]--;
}
crossing++;
if(crossing < N){
oktocross[dir].signal();
}
}

bridge.exit(dir){
crossing--;
if(crossing == 0){
if(countwaiting[dir] != 0){
oktocross[dir].signal();
}else{
oktocross[1-dir].signal();
}
}

}
}
</syntaxhighlight>

== Esercizio g.1==

<syntaxhighlight lang="C">
"Punto a"
123456789123456789123456789...

111111111111111111111111111
22222222222222222222222222 MIN e MAXNUM (infiniti page fault)
3456789993456789993456789

"Punto b"
123453453453453453453453453...

111111111111111111111111111
22222222222222222222222222 MIN e MAXNUM (page fault ad ogni accesso)
3453453453453453453453453

== Esercizio g.1 ==
a)
1234123124123124123...
111111111111111111 ...
22222222222222222 ...
3444333444333444 ...

b)
12343434343...
11144444444...
1222222222...
333333333...

</syntaxhighlight >

==Esercizio c.2==

<syntaxhighlight lang="C">

message database=Queue():

message msgxchange(pid_t pid, message msg)
{
message ris;
asendx(pid,msg);
ris=database.Search(pid,getpid());
if (ris!=NULL)
return ris;
do
{
ris=arecvx();
if (ris.sender!=pid)
database.Add(ris)
}
while (ris.sender!=pid);
return ris;
}
/*
Sì, può provocare deadlock. Es:

A: msgxchange(B,msg);
B: msgxchange(C,msg);
C: msgxchange(A,msg);
*/
</syntaxhighlight>

Lezioni Anno Accademico 2016/17

2017-03-03T22:00:20Z

Mak: /* Lezione del 2 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 = 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", s);
printf("%s", t);
printf("%s", 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
** Shortest job first
** Shortest remaining time first
** Round robin
** Scheduling a priorità
** Scheduler multilivello

== 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

'''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

== Lezione del 7 marzo 2017 ==
== Lezione del 8 marzo 2017 ==
== Lezione del 14 marzo 2017 ==
== Lezione del 16 marzo 2017 ==
== Lezione del 21 marzo 2017 ==
== Lezione del 23 marzo 2017 ==
== Lezione del 28 marzo 2017 ==
== Lezione del 30 marzo 2017 ==
== Lezione del 4 aprile 2017 ==
== Lezione del 6 aprile 2017 ==
== Lezione del 11 aprile 2017 ==
== Lezione del 20 aprile 2017 ==
== Lezione del 27 aprile 2017 ==
== Lezione del 2 maggio 2017 ==
== Lezione del 4 maggio 2017 ==
== Lezione del 9 maggio 2017 ==
== Lezione del 11 maggio 2017 ==
== Lezione del 16 maggio 2017 ==
== Lezione del 18 maggio 2017 ==

Lezioni Anno Accademico 2016/17

2017-03-03T21:57:07Z

Mak: /* Lezione del 2 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 = 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", s);
printf("%s", t);
printf("%s", 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
** Shortest job first
** Shortest remaining time first
** Round robin
** Scheduling a priorità
** Scheduler multilivello

== 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

'''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

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

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

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 n. nella sottoshell. Sono variabili locali.

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

== Lezione del 7 marzo 2017 ==
== Lezione del 8 marzo 2017 ==
== Lezione del 14 marzo 2017 ==
== Lezione del 16 marzo 2017 ==
== Lezione del 21 marzo 2017 ==
== Lezione del 23 marzo 2017 ==
== Lezione del 28 marzo 2017 ==
== Lezione del 30 marzo 2017 ==
== Lezione del 4 aprile 2017 ==
== Lezione del 6 aprile 2017 ==
== Lezione del 11 aprile 2017 ==
== Lezione del 20 aprile 2017 ==
== Lezione del 27 aprile 2017 ==
== Lezione del 2 maggio 2017 ==
== Lezione del 4 maggio 2017 ==
== Lezione del 9 maggio 2017 ==
== Lezione del 11 maggio 2017 ==
== Lezione del 16 maggio 2017 ==
== Lezione del 18 maggio 2017 ==

Lezioni Anno Accademico 2016/17

2017-03-03T20:52:28Z

Mak: /* Lezione del 2 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 = 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", s);
printf("%s", t);
printf("%s", 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
** Shortest job first
** Shortest remaining time first
** Round robin
** Scheduling a priorità
** Scheduler multilivello

== Lezione del 2 marzo 2017 ==

'$' 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$$

== Lezione del 7 marzo 2017 ==
== Lezione del 8 marzo 2017 ==
== Lezione del 14 marzo 2017 ==
== Lezione del 16 marzo 2017 ==
== Lezione del 21 marzo 2017 ==
== Lezione del 23 marzo 2017 ==
== Lezione del 28 marzo 2017 ==
== Lezione del 30 marzo 2017 ==
== Lezione del 4 aprile 2017 ==
== Lezione del 6 aprile 2017 ==
== Lezione del 11 aprile 2017 ==
== Lezione del 20 aprile 2017 ==
== Lezione del 27 aprile 2017 ==
== Lezione del 2 maggio 2017 ==
== Lezione del 4 maggio 2017 ==
== Lezione del 9 maggio 2017 ==
== Lezione del 11 maggio 2017 ==
== Lezione del 16 maggio 2017 ==
== Lezione del 18 maggio 2017 ==

Lezioni Anno Accademico 2016/17

2017-02-24T10:21:54Z

Mak: /* Lezione del 23 febbraio 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 = 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", s);
printf("%s", t);
printf("%s", 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 ==

'''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 ==
== Lezione del 2 marzo 2017 ==
== Lezione del 7 marzo 2017 ==
== Lezione del 8 marzo 2017 ==
== Lezione del 14 marzo 2017 ==
== Lezione del 16 marzo 2017 ==
== Lezione del 21 marzo 2017 ==
== Lezione del 23 marzo 2017 ==
== Lezione del 28 marzo 2017 ==
== Lezione del 30 marzo 2017 ==
== Lezione del 4 aprile 2017 ==
== Lezione del 6 aprile 2017 ==
== Lezione del 11 aprile 2017 ==
== Lezione del 20 aprile 2017 ==
== Lezione del 27 aprile 2017 ==
== Lezione del 2 maggio 2017 ==
== Lezione del 4 maggio 2017 ==
== Lezione del 9 maggio 2017 ==
== Lezione del 11 maggio 2017 ==
== Lezione del 16 maggio 2017 ==
== Lezione del 18 maggio 2017 ==

Lezioni Anno Accademico 2016/17

2016-11-08T23:22:08Z

Mak: /* + implementazione corretta (+j) baton */

Lezioni Anno Accademico 2016/17

2016-11-08T23:08:00Z

Mak: /* syntaxhighlight */

Lezioni Anno Accademico 2016/17

2016-11-08T23:05:20Z

Mak: /* + umask simbolica, esempio ridirezione con dup2() */

Lezioni Anno Accademico 2016/17

2016-11-05T21:44:47Z

Mak: /* Lezione del 4 novembre 2016 */

Lezioni Anno Accademico 2016/17

2016-10-18T21:23:42Z

Mak: /* Lezione del 11 ottobre 2016 */

Lezioni Anno Accademico 2016/17

2016-10-11T23:43:14Z

Mak:

Lezioni Anno Accademico 2016/17

2016-10-11T23:36:51Z

Mak: /* Lezione del 11 ottobre 2016 */

Lezioni Anno Accademico 2016/17

2016-10-11T21:54:39Z

Mak: /* Lezione del 11 ottobre 2016 */

Lezioni Anno Accademico 2016/17

2016-10-11T21:48:34Z

Mak: /* Lezione del 11 ottobre 2016 */

Lezioni Anno Accademico 2016/17

2016-09-27T21:09:39Z

Mak: /* Lezione del 27 settembre 2016 */

Lezioni Anno Accademico 2016/17

2016-09-27T21:06:04Z

Mak: /* Lezione del 27 settembre 2016 */

Lezioni Anno Accademico 2016/17

2016-09-27T20:56:33Z

Mak: /* Lezione del 27 settembre 2016 */