Sezione critica

Sincronizzazione 

• Nell'informatica moderna, il concetto di 

sincronizzazione si riferisce a due importanti 

aspetti 

• Sincronizzazione dei processi 

– Insieme di meccanismi per coordinare 

l'esecuzione di diversi processi/thread 

– Insieme di meccanismi per garantire accesso 

esclusivo ai dati 

• Sincronizzazione dei dati 

– Insieme di meccanismi per mantenere coerenti 

molteplici copie distinte di dati 

1

Sincronizzazione processi e dati 

• Sincronizzazione dei processi 

– Lock 

– Semafori, mutex 

– Thread join 

– Segnali 

• Sincronizzazione dei dati 

– Sincronizzazione dispositivocomputer 

– Clustered file system 

– Coerenza della cache 

– RAID 

– Replicazione DB 

– Journaling 

2

Accesso esclusivo a dati condivisi 

• Nel corso di SO, ci concentriamo sui 

meccanismi di 

– sincronizzazione dei processi 

– accesso esclusivo ai dati condivisi 

• Il focus principale della lezione è sugli accessi 

esclusivi ai dati condivisi 

• Scenario: 

– n processi (o thread) P 0 ,P 1 ,...,P n-1 sequenziali 

cooperanti fra loro 

– tutti i processi in esecuzione asincrona e 

concorrente 

– condivisione di dati (semplici, strutture) 

3

Esempio: il problema bounded buffer 

• In tal senso, un classico scenario è costituito 

dal problema del buffer limitato (bounded 

buffer) 

– vettore di dimensione limitata, contenente m 

buffer 

– vettore condiviso tra n=2 processi 

– un processo “produttore” produce dati e li 

inserisce nel vettore 

– un processo “consumatore” preleva i valori dal 

vettore e li elabora 

• Il problema bounded buffer modella molto 

bene i problemi legati alla gestione 

(inserimento, prelievo) di una lista/coda 

4

Bounded buffer: produttore 

• L'algoritmo del produttore può essere 

sintetizzato come segue 

while (1) { 

while (contatore == DIM_VETTORE) {}; 

vettore[ind_prod] = prodotto; 

ind_prod = (ind_prod + 1) % DIM_VETTORE; 

contatore++; 

} 

5

Bounded buffer: consumatore 

• L'algoritmo del consumatore può essere 

sintetizzato come segue 

while (1) { 

while (contatore == 0) {}; 

consuma = vettore[ind_cons]; 

ind_cons = (ind_cons + 1) % DIM_VETTORE; 

contatore--; 

} 

6

Bounded buffer: concorrenza 

• Se eseguite separatamente, le procedure ora 

descritte funzionano correttamente 

• Se eseguite concorrentemente, le procedure 

ora descritte possono non funzionare 

correttamente 

• ATTENZIONE: 

– L'array vettore[] è condiviso tra i due processi 

produttore e consumatore 

– L'intero contatore è condiviso tra i due processi 

produttore e consumatore 

7


contatore++: 

registro 1 = contatore; 

registro 1 = registro 1 + 1; 

contatore = registro 1 ; 

contatore--: 

registro 2 = contatore; 

registro 2 = registro 2 - 1; 

contatore = registro 2 ; 

8


• registro 1 e registro 2 possono essere lo stesso 

registro 

– context switch ripristina il valore corretto nel 

registro 

• Esecuzione concorrente delle istruzioni 

contatore++ e contatore--: 

– esecuzione sequenziale delle corrispondenti 

operazioni in linguaggio macchina 

– esecuzione interleaved 

♦ordine qualunque, purché preservi l'ordine 

interno delle istruzioni negli algoritmi 

9


T 0 : prod. registro 1 =contatore {registro 1 =5} 

T 1 : prod. registro 1 =registro 1 +1 {registro 1 =6} 

T 2 : prod. contatore=registro 1 {contatore=6} 

T 3 : cons. registro 2 =contatore {registro 2 =6} 

T 4 : cons. registro 2 =registro 2 -1 {registro 2 =5} 

T 5 : cons. contatore=registro 2 {contatore=5} 

• Questa sequenza di istruzioni macchina 

produce il risultato corretto 

10


T 0 : prod. registro 1 =contatore {registro 1 =5} 

T 1 : prod. registro 1 =registro 1 +1 {registro 1 =6} 

T 2 : cons. registro 2 =contatore {registro 2 =5} 

T 3 : cons. registro 2 =registro 2 -1 {registro 2 =4} 

T 4 : prod. contatore=registro 1 {contatore=6} 

T 5 : cons. contatore=registro 2 {contatore=4} 

• Questa sequenza di istruzioni macchina non 

produce il risultato corretto 

• Il risultato dell'operazione dipende dall'ordine 

di esecuzione delle istruzioni macchina 

imposto dallo scheduler 

11

Corsa critica 

• Corsa critica (race condition, race): si ha una 

corsa critica quando l'esecuzione 

interallacciata di istruzioni di due o più 

processi (condividenti dati) dipende dall'ordine 

delle singole istruzioni scelte 

• Nell'esempio visto, per non avere corse 

critiche, è necessario che il codice macchina 

relativo a contatore++ o contatore-- sia 

eseguito atomicamente 

• Sincronizzazione tra processi 

12

Sezione critica 

• Siano dati n processi P 0 ,P 1 ,...,P n-1 

– eseguiti concorrentemente 

– cooperanti tramite dati condivisi 

• Ciascun P j ha una porzione di codice che 

accede ai dati condivisi 

• Sezione critica: sezione di codice che accede a 

dati condivisi 

– va eseguita da al più un processo alla volta 

(mutua esclusione) 

13


• Protocollo di sincronizzazione fra processi per 

l'accesso alla sezione critica 

– sezione di ingresso: il processo chiede il 

permesso di entrare nella sezione critica 

– sezione critica: accesso ai dati condivisi 

– sezione di uscita: rilascio dell'uso della sezione 

critica 

– sezione non critica: codice la cui esecuzione 

non richiede un meccanismo di mutua 

esclusione 

• Attenzione: ciò che si protegge è il codice che 

accede ai dati condivisi 

• Non si protegge del codice che non fa accesso 

a dati condivisi 

14

Protezione delle sezioni critiche 

• Il meccanismo generale di protezione delle 

sezioni critiche si presenta nel formato 

seguente: 

do { 

sezione di ingresso; 

sezione critica; 

sezione di uscita; 

sezione non critica; 

} while (1); 

15


• Ogni soluzione al problema della sezione 

critica deve soddisfare tre requisiti: 

1.mutua esclusione: se P j è in esecuzione, P i non può 

essere eseguito (i != j) 

2.progresso: se 

● nessun processo esegue la sezione critica, 

● alcuni processi vogliono eseguire la sezione 

critica, 

allora solo i processi che non eseguono le 

sezioni non critiche possono decidere 

l'ammissione in sezione critica 

3.attesa limitata: se un processo è in attesa di 

ingresso nella sezione critica, altri processi 

possono eseguire la sezione critica al più k volte (k 

finito) 

16

Meccanismi attivi e passivi 

• Le tecniche di accesso in mutua esclusione 

possono essere suddivise in due categorie: 

tecniche attive e tecniche passive 

• Tecniche attive 

– La CPU monitora costantemente il verificarsi 

dell'evento “la risorsa si libera” 

– Il processo non si blocca 

• Tecniche passive 

– La CPU blocca il processo che intende 

acquisire una risorsa già prenotata 

– Il processo viene svegliato quando la risorsa si 

libera (l'evento si verifica) 

17

La soluzione di Peterson 

• Tecnica interamente software per garantire 

accesso in mutua esclusione ad una sezione 


• Sfortunatamente, tale soluzione può non 

funzionare sulle CPU moderne che, per motivi 

di efficienza, fanno reordering delle istruzioni 

• Essa rappresenta, tuttavia, un buon esempio di 

come affrontare le difficoltà legate al 

soddisfacimento dei requisiti per l'accesso in 

mutua esclusione 

18


• Due processi P 0 e P 1 si alternano nella loro 

esecuzione 

• Per comodità di rappresentazione, l'algoritmo 

sarà descritto tramite due indici: 

– Indice i: indice del processo che sta eseguendo 

codice sulla CPU locale 

– Indice j: indice dell'altro processo (j=1-i) 

• I due processi condividono due informazioni 

– Una variabile intera turn, contenente l'indice del 

processo abilitato ad entrare in sezione critica 

– Un array di boolean flag[2] che, per ciascun 

processo, mi dice se tale processo è pronto per 

entrare in sezione critica 

19


• La soluzione di Peterson è rappresentata 

dall'algoritmo seguente (processo P i ): 

do { 

flag[i] = TRUE; 

turn = j; 

while (flag[j] && turn==j); 


flag[i] = FALSE; 

} while (1); 

Sezione di ingresso 

Sezione di uscita 

20


• Sono verificati i requisiti per il corretto 

accesso in mutua esclusione? 

• Requisito 1: mutua esclusione 

– P i entra nella sua sezione critica solo se fallisce 

il while, ossia flag[j]==false o turn==i 

– se P 0 e P 1 fossero in sezione critica nello stesso 

istante, si avrebbe flag[0]==TRUE, 

flag[1]==TRUE 

– le due oss. precedenti implicano che turn=0 e 

turn=1 contemporaneamente 

– assurdo -> P 0 e P 1 non possono mai eseguire la 

sezione critica concorrentemente 

21




• Requisito 2: progresso 

– P i non entra in sezione critica fino a quando 

viene eseguito il ciclo while 

(flag[j]==TRUE e turn==j) 

– se P j non è pronto ad entrare in sezione critica, 

imposta flag[j]==false, ed entra P i 

– se invece P j entra in sezione critica, quando 

esce imposta flag[j]=false e P i entra in sezione 


– progresso (P i e P j si alternano) 

22




• Requisito 3: attesa limitata 

– La dimostrazione precedente (requisito 2) ha 

mostrato come P i e P j si alternino 

nell'esecuzione della sezione critica 

– Se un processo è in attesa di entrare in sezione 

critica, l'altro processo può eseguire la sezione 

critica al più k=1 volte 

23

Strumenti moderni per la 

sincronizzazione 

• La soluzione di Peterson, pur essendo basata 

completamente su software 

– è complessa 

– mal sopporta ottimizzazioni sul codice da parte 

della CPU e del SO 

• Nei moderni SO, le sezioni di ingresso e di 

uscita sono implementate tramite un modello 

universale: il lock (serratura, lucchetto) 

• Si protegge una sezione critica che accede a 

dati condivisi con 

– una variabile intera che indica se la risorsa è 

libera oppure occupata 

– un meccanismo che controlla lo stato della 

variabile intera e permette l'accesso esclusivo 

24

Modello di locking/unlocking 

• Il meccanismo generale di protezione delle 

sezioni critiche tramite lock si presenta nel 

formato seguente: 

do { 

 


 

sezione non critica; 

} while (1); 

25

Supporto hardware al locking 

• Molte architetture offrono particolari istruzioni 

che permettono di leggere/scrivere il 

contenuto della memoria in modalità atomica 

– Esecuzione atomica: esecuzione non 

interrompibile (tutto o niente) 

– La tipica operazione atomica è un controllo di 

una variabile con contestuale modifica 

• Le operazioni di locking sono spesso 

implementate tramite tali istruzioni macchina 

• Le istruzioni macchine permettono di 

implementare meccanismi di attesa attiva 

26

Supporto hardware al locking 

• Serve davvero un meccanismo di locking di 

questo tipo? 

• Sistemi single processor 

– Non è necessario un meccanismo di locking 

atomico 

– Basta disabilitare le interruzioni durante la 

esecuzione della sezione critica 

• Sistemi multiple processor: 

– Non basta disabilitare le interruzioni sulla CPU 

locale, perché l'accesso concorrente potrebbe 

avvenire da una altra CPU 

– Bisognerebbe spegnere le interruzioni su tutte 

le CPU; tuttavia, il sistema non scalerebbe più 

– le sezioni critiche devono essere protette 

27

Istruzione TestAndSet 

• L'istruzione macchina TestAndSet effettua le 

seguenti operazioni atomicamente: 

– ritorna il vecchio valore di una variabile 

– imposta la variabile al valore TRUE (1) 

boolean TestAndSet (boolean *obiettivo) { 

} 

boolean valore = *obiettivo; 

*obiettivo = TRUE; 

return valore; 

28

Locking/Unlocking con TestAndSet 

• Si usa una variabile intera blocco per 

contenere l'informazione “risorsa libera o 

occupata” 

– blocco=FALSE: la risorsa è libera 

– blocco=TRUE: la risorsa è occupata 

do { 

while (TestAndSet(blocco)); 


blocco = FALSE; 

} while (1); 

29

Locking/Unlocking con TestAndSet 

blocco 

1 

0 t * 

blocco=FALSE 

t 

30

Istruzione Swap 

• L'istruzione Swap effettua le seguenti 

operazioni atomicamente: 

– scambia i valori di due variabili a e b 

void Swap(boolean *a, boolean *b) { 

} 

boolean temp = *a; 

*a = *b; 

*b = temp; 

31

Locking/Unlocking con Swap 

• Si usano due variabile intere: 

– blocco: FALSE se la risorsa è libera, TRUE se la 

risorsa è occupata 

– chiave: variabile di aiuto per lo swap 

do { 

chiave = TRUE; 

while (chiave==TRUE) { 

Swap(blocco, chiave); 

} 


blocco = FALSE; 

} while (1); 

32

locco 

Locking/Unlocking con Swap 

1 

0 t * 

blocco=FALSE 

t 

33

Istruzioni hw e mutua esclusione 

• TestAndSet e Swap non soddisfano il criterio 

di attesa limitata 

• TestAndSet e Swap vanno integrate con un 

supporto (algoritmo) per permettere l'attesa 

limitata 

34

Semafori 

• Le soluzioni al problema della sezione critica 

viste in precedenza sono vincolate al 

particolare tipo di problema 

• Esiste un meccanismo più generale? 

– Meccanismo semplice per decidere se utilizzare 

o meno una risorsa condivisa tramite una 

sezione critica 

– Mascherare le particolarità della applicazione 

(niente riferimenti a struttura dati interne tipo 

flag[]) 

• Il meccanismo esiste e prende il nome di 

semaforo 

– Il nome non è casuale: emula un vero e proprio 

semaforo stradale 

35

Semafori 

• Semaforo: variabile intera S, che conta il 

numero di slot di uso della risorsa condivisa 

• La variabile S viene acceduta solo tramite due 

funzioni: 

– wait(S): sezione di accesso (originariamente 

chiamata P(), dall'olandese proberen, ossia 

“testare”) 

– signal(S): sezione di uscita (originariamente 

chiamata V(), dall'olandese verhogen, ossia 

“incrementare”) 

36

wait() e signal() 

• Lo scheletro implementativo delle funzioni 

wait() e signal() è il seguente 

wait(S) { 

while( S

Semafori contatore e binari 

• Dal punto di vista degli slot di risorsa messi a 

disposizione, si possono distinguere due 

categorie di semafori: semafori contatore e 

semafori binari 

• Semafori contatore: 

– S è inizializzata ad un valore > 1 

– Una risorsa che può elaborare S > 1 elementi 

concorrentemente 

• Semafori binari: 

– S è inizializzata ad 1 (caso comune) 

– O uso la risorsa, o non la uso 

– Viene anche detto mutex (MUTual EXclusion) 

38

Semafori attivi e passivi 

• Il modello di semaforo ora presentato è attivo 

(busy waiting) 

– Dal punto di vista funzionale, somiglia in 

maniera sinistra ai meccanismi di locking hw 

• Un semaforo attivo prende il nome di spinlock 

– La CPU continua a ciclare (spin) sul while, 

bloccando (lock) l'accesso 

• Esiste un modello passivo di semaforo? 

39

Semafori attivi e passivi 

• In generale, un semaforo può essere 

implementato in due modalità distinte: 

– busy waiting (spinlock): la CPU controlla 

attivamente il verificarsi della condizione di 

accesso alla sezione critica 

♦scalabile, veloce 

♦CPU-intensive 

♦adatto per attese brevi (accesso a memoria) 

– sleep (mutex,semaforo): il processo viene 

messo in attesa (sleep) che si verifichi la 

condizione di accesso alla sezione critica 

♦più lento 

♦adatto per attese lunghe (I/O) 

40

Struttura semaforo passivo 

• Nel caso passivo, il semaforo diventa una 

struttura dati contenente: 

– la singola variabile intera S, che conta il numero 

di slot associati alla risorsa 

– una lista di processi che attendono lo sblocco 

della risorsa 

typedef struct { 

int valore; 

struct processo *p; 

} semaforo; 

puntatore alla lista dei 

processi in attesa di 

entrare nella sezione 


41

Semaforo passivo: wait() 

• La funzione wait(S) si estende con il supporto 

di accodamento dei processi 

void wait(semaforo S) { 

S.valore--; 

if (S.valore < 0) { 

; 

} 

} 

block(); 

mette il processo in stato 

di attesa 

42

Semaforo passivo: signal() 

• La funzione signal(S) si estende con il 

supporto di prelievo di un processo dalla coda 

void signal(semaforo S) { 

S.valore++; 

if (S.valore

Dettagli implementativi 

• Osservazioni 

– le funzioni block() e wakeup() devono essere 

fornite dal SO 

– il criterio di estrazione usato nella wakeup() è, 

generalmente, FIFO, ma può non essere il solo 

– l'esecuzione di wait() e signal() è atomica 

♦wait() e signal() considerate come vere e 

proprie sezioni critiche 

– nelle versioni bloccanti, l'attesa attiva non è 

completamente eliminata; è limitata alla attesa 

attiva della sezione critica wait()/signal() 

(abbastanza breve) 

44

Problemi: stallo 

• Nell'implementazione bloccante dei semafori, 

può capitare, a seguito di un errore 

implementativo, che: 

– un insieme di processi attenda il verificarsi 

di un evento 

– l'evento in questione può essere causato 

solo da uno dei processi in attesa 

• Tale situazione prende il nome di stallo 

(deadlock) 

45

P 0 

wait(S); 

wait(Q); 

... 

signal(S); 

signal(Q); 

Problemi: stallo 

P 1 

wait(Q); 

wait(S); 

... 

signal(Q); 

signal(S); 

Errore tipico: 

non viene preservato l'ordine 

di richiesta/rilascio delle sezioni critiche 

46

Problemi: attesa indefinita 

• In generale, si evita il criterio LIFO (stack) nella 

gestione della coda dei processi in attesa della 

sezione critica 

• Il criterio LIFO favorisce gli ultimi processi e 

non i primi 

• Attesa indefinita dei processi più vecchi 

• Si adotta il criterio FIFO (coda) 

– Le wait queue del kernel 

47

Problemi tipici di sincronizzazione 

• Problema produttore-consumatore con 

memoria limitata 

– vettore di n posizioni 

– ciascuna posizione gestisce un elemento 

– un processo produttore di elementi 

– un processo consumatore di elementi 

– si implementa con tre semafori: 

♦vuote: conta le posizioni vuote del vettore 

(inizializzato ad n) 

♦piene: conta le posizioni piene del vettore 

(inizializzato a 0) 

♦mutex: gestisce la mutua esclusione al 

vettore (inizializzato a 1) 

48




Processo produttore 

do { 

appena_prodotto = ; 

wait(vuote); 

wait(mutex); 

; 

signal(mutex); 

signal(piene); 

} while (1); 

49




Processo consumatore 

do { 

wait(piene); 

wait(mutex); 

; 

da_consumare=; 


signal(vuote); 

} while (1); 

50


• Problema dei lettori e degli scrittori 

– n processi concorrenti agenti su un insieme di 

dati (ad esempio, un file) 

– alcuni processi sono lettori 

– gli altri processi sono scrittori 

– più lettori possono accedere concorrentemente 

all'insieme dei dati 

– ciascuno scrittore ha accesso esclusivo 

all'insieme dei dati 

51


• Problema dei lettori e degli scrittori 

– num_lettori: intero condiviso che indica il 

numero di processi attualmente in lettura 


– due semafori: 

♦mutex: garantisce l'accesso in mutua 

esclusione a num_lettori (inizializzato a 1) 

♦scrittura: garantisce l'accesso in scrittura 

mutuamente esclusiva alla risorsa 


52


• Problema lettore-scrittore 

Processo scrittore 

wait(scrittura); 

; 

signal(scrittura); 

53


• Problema lettore-scrittore 

Processo lettore 

wait(mutex); 

num_lettori++; 

if (num_lettori == 1) 

wait(scrittura); 


 

wait(mutex); 

num_lettori--; 

if (num_lettori == 0) 

signal(scrittura); 


aggiornamento di num_lettori in 

mutua esclusione tra i lettori 

se non ho lettori, prima di 

leggere, aspetta uno scrittore 

permetti ad un altro lettore di 

avanzare 

aggiornamento di num_lettori in 

mutua esclusione tra i lettori 

se non ho lettori, permetti ad 

un'altro scrittore di avanzare 

permetti ad un altro lettore di 

avanzare 

54


• Problema dei cinque filosofi 

– 5 filosofi mangiano e pensano 

– sono seduti ad un tavolo rotondo 

– la tavola è apparecchiata con 5 bacchette, 5 

piatti ed 1 scodella di riso 

– quando 1 filosofo pensa, non interagisce con gli 

altri 

– quando 1 filosofo mangia: 

♦prova a prendere le bacchette, una alla volta 

♦se ci riesce, mangia a sazietà 

♦al termine del pasto, lascia le bacchette e si 

rimette a pensare 

55


Cartesio 

Platone 

Voltaire Socrate 

Confucio 

56



– i filosofi non possono mangiare tutti 

contemporaneamente (mancano le bacchette) 

– voglio evitare lo stallo, in cui ciascun filosofo 

prende la bacchetta di sinistra 

– il problema dei cinque filosofi rappresenta una 

classe di problemi ben definita: 

♦assegnazione di risorse limitate a diversi 

processi, senza creare situazioni di stallo 

– Bacchette=Risorse 

– Provo ad associare a ciascuna bacchetta un 

semaforo 

57



do { 

wait(bacchetta[i]); 

wait(bacchetta[(i+1) % 5]); 

; 

signal(bacchetta[i]); 

signal(bacchetta[(i+1) % 5]); 

 

} while (1); 

prova a prendere le 

bacchette alla mia 

destra e sinistra 

rilascia le 

bacchette alla mia 

destra e sinistra 

58



– questa soluzione non è in grado di evitare lo 

stallo 

♦tutti i filosofi tentano di afferrare la bacchetta 

alla loro sinistra 

– bacchetta[i]=0 per ogni i 

– wait(bacchetta[(i+1)] % 5]) stalla 

♦i filosofi muoiono tutti di fame 

– starvation dei processi 

59



– Possibili soluzioni: 

♦far sedere al tavolo al più 4 filosofi (limitare il 

numero di processi richiedenti la risorsa) 

♦un filosofo può prendere le bacchette solo se 

entrambe disponibili (il processo o prende 

tutte le risorse di cui ha bisogno in mutua 

esclusione o non progredisce) 

♦un filosofo dispari prende prima la bacchetta 

di sinistra e poi quella di destra, un filosofo 

pari fa il contrario (asimmetria delle richieste 

spezza la catena di stallo) 

60

Sezione critica

Trasformi i suoi PDF in rivista online e aumenti il suo fatturato!

Delete template?

Save as template ?