La successiva scelta di progettazione da fare è su la metafora in base alla quale impostare il modello di programmazione per la gestione della concorrenza.
Sono due le metafore più comuni, la prima è il modello a sincronizzazione in cui due (e più) istanze su due differenti thread si scambiano messaggi per coordinarsi nel fare i compiti/operazioni/calcoli necessari all'applicazione. Mentre l'altra è il modello a competizione in cui due (e più) istanze su due differenti thread competono per usare in modo esclusivo un'istanza che è in esecuzione su entrambi i thread (*).
-
Il modello a sincronizzazione
è detto anche produttore-consumatore perchè come in una catena di montaggio una istanza in un thread "consuma" i risultati "prodotti" dall'istanza in esecuzione sull'altro thread.
Un esempio è un programma di masterizzazione in cui una istanza su di un thread legge i dati dal lettore CD e una su un altro thread li salva sul masterizzatore. Un'istanza nel thread di "scrittura" manda un messaggio di send e resta in attesa di avere dati da salvare, l'istanza nel thread di lettura risponde con un buffer di dati e poi prosegue a leggere.
-
Il modello a competizione
è detto anche a variabili condivise su cui istanze che girano su thread differenti ci leggono e scrivono e vogliono farlo in modo esclusivo per leggere in modo consitente lo stato delle variabili e modificarlo in modo consistente.
Ad esempio una applicazione Web di registrazione ordini che serve diversi client su thread diversi ogniuno dei quali accede in modo esclusivo ai dati di magazzino per acaparrarsi in modo esclusivo la disponibilità di un articolo.
Il modello a sincronizzazione è adatto ad applicazioni in cui ... è naturale modellare il compito che l'applicazione svolge con una combinazione di coppie produttore-consumatore. Una modellazione a work-flow.
Tipicamente il numero di thread è fisso e il compito di ogni thread è noto a priori.
il modello a sincronizzazione è adatto ad applicazioni in cui ... è naturale modellare le risorse/variabili/istanze che saranno accessibili e condivise tra più thread.
Tipicamente le istanze condivise tra thread diversi sono fisse e note a priori e spesso lo è anche il compito dei thread mentre il loro numero può cambiare dinamicamente a run-time (ad esempio a seconda del numero di client serviti).
(*) Queste metafore interessano per il disegno della applicazione. Il fatto che ci sono primitive di programmazione della concorrenza che adottano queste metafore (lo scambio di messaggi send/receive con rendezvous e le sezioi critiche) confonde un pò.
Tags : Progettazione Software |