Perché dovresti usare un monitor anziché un semaforo?

Attualmente sto frequentando il corso di programmazione concorrente nella mia università e recentemente abbiamo iniziato a parlare del concetto di monitor. Mentre capisco la necessità dell'esclusione reciproca, non capisco perché dovrei usare un monitor per quello.

A quanto ho capito, un monitor garantisce che esattamente uno o nessun processo è sempre nella sezione critica. Possiamo ottenere esattamente questo con un semaforo. Inoltre implementiamo monitor (o almeno una possibilità per implementarli è) con semafori.

Quindi perché dovrei implementare qualcosa che fa esattamente la stessa cosa di un semaforo con un semaforo? Quali vantaggi ottengo?

Sono quasi intercambiabili e uno può essere costruito dall'altro. È in qualche modo dipendente dalla lingua che viene implementato / preferito (ad esempio Java ha monitor integrati che usano la parola chiave "sincronizza"). Tuttavia, il semaforo è considerato un'entità di "livello inferiore" rispetto al monitor per i seguenti motivi e differenze:

Sia i monitor che i semafori vengono utilizzati per lo stesso scopo: la sincronizzazione dei thread. Ma i monitor sono più semplici da usare dei semafori perché gestiscono tutti i dettagli dell'acquisizione e del rilascio dei blocchi. Un'applicazione che utilizza i semafori deve rilasciare tutti i blocchi acquisiti da un thread al termine dell'applicazione, ciò deve essere fatto dall'applicazione stessa. Se l'applicazione non lo fa, nessun altro thread che necessita della risorsa condivisa non potrà procedere.

Un'altra differenza nell'uso dei semafori è che ogni routine che accede a una risorsa condivisa deve acquisire esplicitamente un blocco prima di utilizzare la risorsa. Questo può essere facilmente dimenticato quando si codificano le routine relative al multithreading. I monitor, a differenza dei semafori, acquisiscono automaticamente i blocchi necessari. [1]

Vedi anche la risposta molto votata allo StackTranslate.it Semaphore vs. Monitors: qual è la differenza? con una grande / memorabile analogia con i bagni pubblici e le rastrelliere per biciclette.

Alla fine abbiamo discusso del motivo per cui nella lezione di oggi useresti un monitor anziché un semaforo.

Fondamentalmente si riduce a questo: il monitor e il semaforo sono ugualmente espressivi, il che significa che puoi trovare una soluzione per un problema con un monitor in cui originariamente veniva usato un semaforo e viceversa.

Bene, lo sapevamo già, quindi perché dovresti usare un monitor anziché un semaforo?

Preferenza personale. Normalmente un'applicazione desktop userebbe i monitor, lasciando meno possibilità di errori, ma, come compromesso, avendo una struttura relativamente gonfia. D'altra parte, i semafori vengono spesso utilizzati nei sistemi operativi, in quanto sono una struttura leggera, ma lasciano più possibilità di errori.

Immagino che possiamo concludere che si tratta di una decisione situazionale, indipendentemente dal fatto che tu abbia bisogno / voglia di usare un monitor o un semaforo. Se costruisci un sistema in tempo reale potresti voler andare con un semaforo, se stai costruendo un programma per ufficio potresti anche andare con un monitor.

Dai un'occhiata ad esempio "Il piccolo libro dei sempaphores"di Allen B. Downey. afferma e risolve molti problemi di sincronizzazione. Controlla in particolare le soluzioni pasticciate e vedrai che i semafori sono un meccanismo di livello molto basso, molto potente ma estremamente facile da usare in modo improprio, in cui semplici errori hanno terribili consecuenze (aggravati anche dall'intrinseca operazione non deterministica di programmi concorrenti). È ad esempio facile dimenticare di applicare l'esclusione reciproca, operare su un semaforo sbagliato e così via. I monitor offrono soluzioni preconfezionate ai casi più utilizzati e portano con sé la maggior parte dei vantaggi della programmazione orientata agli oggetti (ovvero, sai che l'unico modo per pasticciare con le variabili gestite dal monitor è attraverso le sue operazioni). Lo svantaggio è che non possono essere facilmente adattati in linguaggi non orientati agli oggetti,