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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?