Che cos'è la concorrenza guidata da eventi?

Question

Sto iniziando a imparare Scala e la programmazione funzionale. Stavo leggendo il libro! Programming scala: Tackle Multi-Core Complexity sulla Java Virtual Machine. "Nel primo capitolo ho visto la parola Event-Driven modello di concorrenza e attore .Prima di continuare a leggere questo libro voglio avere un idea di concorrenza Event-Driven o Attore modello.

Qual è la concorrenza Event-Driven, e come è collegato con l'attore modello?

Answer 1

un modello di programmazione Event Driven comporta la registrazione del codice da eseguire quando un determinato evento viene Un esempio è, invece di chiamare un metodo che restituisce alcuni dati da un database:

val user = db.getUser(1) 
println(user.name) 

Y ou potrebbe invece registrare un callback da eseguire quando i dati sono pronti:

db.getUser(1, u => println(u.name)) 

Nel primo esempio, senza la concorrenza stava accadendo; Il thread corrente bloccherebbe fino a db.getUser(1) restituiti dati dal database. Nel secondo esempio, db.getUser ritornerebbe immediatamente e continuerà a eseguire il codice successivo nel programma. Parallelamente, la callback u => println(u.name) verrà eseguita in futuro.

Alcune persone preferiscono il secondo approccio in quanto non significa che i thread affamati di memoria sono inutilmente seduti in attesa di un I/O lento per il ritorno.

Il modello di attore è un esempio di come i concetti di Event-Driven possono essere utilizzati per aiutare il programmatore a scrivere facilmente programmi concorrenti.

Da un livello molto alto, gli attori sono oggetti che definiscono una serie di gestori di messaggi guidati da eventi che vengono attivati ​​quando l'attore riceve messaggi. In Akka, ogni istanza di un attore è single threaded, tuttavia quando molti di questi attori vengono messi insieme creano un sistema con concurrency.

Ad esempio, l'attore A potrebbe inviare messaggi all'attore B e C in parallelo. L'attore B e C potrebbero richiamare i messaggi sull'attore A. L'attore A avrebbe i gestori di messaggi per ricevere questi messaggi e comportarsi come desiderato.

Per ulteriori informazioni sul modello di attore, consiglierei di leggere la documentazione di Akka. E 'davvero ben scritto: http://doc.akka.io/docs/akka/2.1.4/

C'è anche il lotto di buona documentazione giro per il web su Event Driven concorrenza che ci molto più dettagliato di quello che ho scritto qui. http://berb.github.io/diploma-thesis/original/055_events.html

Answer 2

La risposta di Theon offre una buona panoramica moderna. Mi piacerebbe aggiungere una prospettiva storica.

Tony Hoare e Robert Milner hanno entrambi sviluppato algebra matematica per l'analisi di sistemi concorrenti (Comunicare processi sequenziali, CSP e Comunicare sistemi concorrenti, CCS). Entrambi sembrano una matematica pesante per molti di noi, ma l'applicazione pratica è relativamente semplice. CSP ha portato direttamente al linguaggio di programmazione Occam, tra gli altri, con Go che è l'ultimo esempio. CCS ha portato al calcolo del Pi e alla mobilità delle estremità del canale di comunicazione, una caratteristica che fa parte di Go ed è stata aggiunta a Occam nell'ultimo decennio.

Concorrenza di modelli CSP considerando esclusivamente entità automomiche ("processi", v.cose leggere come fili verdi) che interagiscono semplicemente per scambio di eventi. Il mezzo per passare eventi è lungo i canali. I processi possono dover gestire diversi input o output e lo fanno selezionando l'evento che è pronto per primo. Gli eventi di solito portano dati dal mittente al destinatario.

Una caratteristica principale del modello CSP è che una coppia di processi si impegna nella comunicazione solo quando entrambi sono pronti - in termini pratici ciò porta a quella che viene solitamente definita comunicazione "sincrona". Tuttavia, le implementazioni effettive (Go, Occam, Akka) consentono il buffering dei canali (lo stato normale in Akka) in modo che lo scambio di eventi lock-step sia spesso effettivamente disaccoppiato.

Quindi, in sintesi, un sistema basato su CSP basato sugli eventi è in realtà una rete di flussi di dati collegati da canali.

Oltre all'interpretazione CSP dell'evento, ce ne sono stati altri. Un esempio importante è l'approccio "ruota degli eventi", una volta apprezzato per la modellazione di sistemi concorrenti, mentre in realtà ha un singolo thread di elaborazione. Tali sistemi gestiscono gli eventi mettendoli in una coda di elaborazione e gestendoli a tempo debito, solitamente tramite una richiamata. Il motore di elaborazione degli eventi di Java Swing è un buon esempio. Ce n'erano altri, ad es. per i motori di simulazione basati sul tempo. Si potrebbe pensare che il modello Javascript/NodeJS si adatti anche a questa categoria.

Quindi, in sintesi, una ruota di eventi era un modo per esprimere la concorrenza ma senza parallelismo.

L'ironia di questo è che i due approcci che ho descritto sopra sono entrambi descritti come eventi guidati, ma ciò che significano per evento guidato è diverso in ciascun caso. In un caso, le entità di tipo hardware sono collegate insieme; nell'altro, quasi tutte le azioni sono eseguite da callback. L'approccio CSP afferma di essere scalabile perché è completamente componibile; è naturalmente abile anche nell'esecuzione parallela. Se ci sono motivi per preferire l'uno all'altro, probabilmente lo sono.