Monitor

Questo è un modo di più alto livello per creare programmazione concorrente.

Introduzione ai monitor

Questo costrutto per la programmazione concorrente, prende molto dalla programmazione agli oggetti, abbiamo delle variabili presenti al monitor, private solamente accessibili ad essa, tramite procedure che sono mutex automaticamente!

Elementi costituenti 🟩

• Dati locali
• Sequenza di inizializzazione
• Procedure di entrata

Appena provo a chiamare una procedura, questa è fatta già in mutua esclusione!.

E possono modificare dati locali solo tramite chiamate a sue procedure

• Cose in slide

  

Variabili di condizione 🟩

Queste sono variabili utilizzate per sincronizzare l’accesso,

• Strutture classiche

  

Politica del signal urgent (!) 🟩

• Slide

  

L’idea è molto simile a quanto fatto per i signal presenti in Semafori, se qualcuno è in attesa, dai subito il bastone a lui, altrimenti non fai niente.

Questa è la politica di signalling che viene usata implicitamente in esame.

Altre politiche di signalling (3) 🟨

• Slide

  

Differenze con semafori (3) 🟩-

• Slide

  

Sembrano simili la Wait e la signal con P e la V, ma sono cose totalmente diverse!!!!.

• Signal non ha nessun effetto se non ci sono processi in attesa, mentre V memorizza sempre
• Wait è sempre bloccante! mentre P no…
• Il processo risvegliato è sempre eseguito per primo! (signal urgent).

Implementazione dei semafori con monitor 🟩

• Slide

  

È una implementazione molto facile! Per questo motivo ci piace abbastanza 😀

Implementazione monitor con semafori 🟨+

• Slide

  

Problemi classici con monitor

Readers and writers 🟨+

la parte difficile di questa parte è scrivere bene le invarianti, quindi è molto più facile scrivere una soluzione una volta che si sa.

• Driver code

  

• ReaderWriter controller

  

• Versione senza starvation !!!

  

Producer and consumers 🟩

• Soluzione producer and consumers

  

Buffer limitato 🟩

• Sol

  

Questa soluzione con i semafori è molto più clean rispetto a quello dei semafori!

basta andare a verificare che le invarianti siano soddisfatte, riguardanti la possibilità di scrittura e la possiblità di lettura.

Filosofi a cena

• Sol

  

• Driver code, dal punto di vista del filosofo

  

• Without deadlock

  

• Without deadlock, all destri!

  

• Soluzione con chopsticks

  

una cosa molto bella è che che non è deadlock nemmeno se sono tutti destri! il motivo è che l’accesso è sempre in mutua esclusione, il primo che va a prenderli è buona roba.

• Ulteriori delucidazioni su questa roba

  Supponiamo per assurdo che ci sia deadlock per la versione in cui i filosofi sono tutti destri. Supponiamo che siamo al filosofo $i$, questo prende la sua bacchetta, e deve aspettare la bacchetta successiva, fino a creare il ciclo. fino a qui abbiamo enunciato quello che deve succedere affinché ci sia deadlock. Ma questo non può succedere perché ogni filosofo guarda da solo se può prenderlo o meno (mi sembra che questa soluzione sia un poco meno efficiente rispetto a quello con i semafori, perché solamente un filosofo può prendere…)