Vantaggi della programmazione concorrente

Su un sistema uniprocessore, programmare un'applicazione con un insieme di processi/thread concorrenti può avere diversi vantaggi:

• semplicità di programmazione, se l'applicazione prevede più compiti
• efficienza, se si ha parallelismo tra attività di CPU e di I/O
• possibilità di assegnare compiti più urgenti a processi/thread con priorità più elevata, se lo scheduler si basa sulle priorità

Inoltre, se il processore è multithreading, oppure il sistema è multiprocessore, i vantaggi in termini di efficienza sono ancora più significativi.

La programmazione concorrente presenta però alcune importanti problematiche, legate all'interazione tra processi/thread diversi.

Memoria condivisa

Nella discussione che segue, si suppone che più processi abbiano una zona di memoria condivisa. Di norma, i processi hanno memoria separata, ma

• le strutture dati che il kernel usa per gestire i processi sono effettivamente condivise da tutti i processi
• molti SO mettono a disposizione delle system call che permettono ai processi di ottenere una porzione di memoria condivisa
• le stesse problematiche analizzate in seguito si possono avere tra thread (che, per definizione, hanno memoria condivisa), oppure tra processi che usano file condivisi.

Esempio

Un esempio di memoria condivisa potrebbe essere un sistema banale di prenotazioni aeree, che usa $n$ terminali connessi a un computer centrale. Questo sistema assegna i posti in ordine sequenziale finchè non sono esauriti.

Si ha un processo per ciascuno degli $n$ terminali, e tutti i processi condividono due variabili:

• next_seat: indica il prossimo posto da assegnare
• max: indica il numero totale di posti sul volo

Il programma che gli $n$ terminali eseguono per prenotare un posto sul volo è: