Quando si dovrebbe usare il modello di attore?

Question

Quando deve essere utilizzato lo Actor Model?

Certamente non garantisce un ambiente senza deadlock.

Attore A può attendere un messaggio da B mentre B attende A.

Inoltre, se un attore deve assicurarsi che il suo messaggio è stato elaborato prima di passare al suo prossimo compito, dovrà inviare un messaggio e attendi il messaggio "il tuo messaggio è stato elaborato" invece del semplice blocco.

Qual è il potere del modello?

Answer 1

Dato un problema di concorrenza, che cosa cercheresti per decidere se utilizzare o meno gli attori?

Per prima cosa vorrei cercare di definire il problema ... la motivazione principale è l'accelerazione di un ciclo annidato o ricorsione? Se è così, un approccio basato su un semplice compito o un ciclo in parallelo probabilmente funzionerà bene per voi (piuttosto che per gli attori).

Tuttavia, se si dispone di un sistema più complesso che coinvolge dipendenze e che coordinano lo stato condiviso, un approccio attore può essere d'aiuto. In particolare, attraverso l'uso di attori e la semantica del messaggio, è spesso possibile evitare l'uso di blocchi espliciti per proteggere lo stato condiviso realizzando effettivamente copie di quello stato (messaggi) e reagendo a tali stati.

Si può fare abbastanza facilmente con i classici problemi di sincronizzazione come i filosofi del pranzo e il problema dei barbieri addormentati. Ma puoi anche usare l''attore' per aiutare con schemi più moderni, cioè la tua facciata potrebbe essere un attore, la tua vista modello e il controller potrebbero anche essere attori che comunicano tra loro.

Un'altra cosa che ho osservato è che la semantica degli attori è apprendibile dalla maggior parte degli sviluppatori e "più sicura" rispetto alle controparti bloccate. Questo perché innalzano il livello di astrazione e consentono di concentrarsi sul coordinamento dell'accesso a tali dati anziché proteggere tutti gli accessi ai dati con i blocchi. Ad esempio, immagina di avere una classe semplice con un membro dati. Se si sceglie di inserire un blocco in tale classe per proteggere l'accesso a tale membro dati, qualsiasi metodo su quella classe dovrà garantire che acceda a quel membro dati sotto il blocco. Questo diventa particolarmente problematico quando altri (o voi) modificano la classe in un secondo momento, devono ricordare per utilizzare quel blocco.

D'altra parte se quella classe diventa un attore e il membro dati diventa un buffer o una porta con cui comunichi tramite messaggi, non devi ricordarti di prendere il blocco perché la semantica è incorporata nel buffer e tu saprai in modo esplicito se stai andando a bloccarlo in base al tipo di buffer.

-Rick

Answer 2

L'utilizzo di attore è "naturale" in almeno due casi:

1. Quando si può scomporre il problema in un insieme di attività indipendenti.
2. Quando è possibile scomporre il problema in una serie di attività collegate da un chiaro flusso (ad esempio dataflow programming).

Ad esempio, se si elaborano dati complessi utilizzando una serie di filtri, è facile utilizzare una pipeline di attori in cui ogni attore riceve i dati da un attore upstream e imposta i dati su un attore downstream.

Ovviamente questo flusso di dati non deve essere lineare e se un passaggio è lento nella pipeline, è possibile utilizzare invece un pool di attori che svolgono lo stesso lavoro. Un altro modo per risolvere i problemi di bilanciamento del carico sarebbe utilizzare un approccio basato sulla domanda organizzato con una sorta di sistema virtuale Kanban.

Naturalmente avrete bisogno di sincronizzazione tra attori in quasi tutti i casi interessanti, ma contrariamente al classico approccio multi-thread, questa sincronizzazione è davvero "concreta". Potete immaginare ragazzi in una fabbrica, immaginare possibili problemi (gli operai non hanno lavoro da svolgere, le operazioni a monte sono troppo veloci ei prodotti intermedi necessitano di un enorme spazio di archiviazione, ecc.). Per analogia, è possibile trovare una soluzione più facilmente.