Wie werden Akka-Akteure auf zugrunde liegenden Threads implementiert?

Question

Wie werden Akka/Scala-Akteure bei einem Ausführungskontext und einem Thread-Pool geplant/implementiert?

Answer 1

Sie können relevante Informationen in der akka documentation finden, die ziemlich vollständig ist, soweit die Sache geht.

Im Wesentlichen können Sie Dispatcher auswählen und definieren und diesen durch Konfiguration (über Dateien oder Code) zuweisen.

Jede Dispatcher-Implementierung basiert dann auf einer Art Executor.

Answer 2

On 'Ich habe mir etwas genaueres angesehen, zum Beispiel, dass man einen Thread-Pool von 10 Threads und 50 Darstellern erhält, wie werden so viele Schauspieler durch einen Stapel von 10 Threads behandelt?'

Das genaue Verhalten hängt vom Dispatcher und der Konfiguration ab. Allerdings haben die meisten Disponenten im Grunde so etwas wie diese:

• Wählen Sie einen Schauspieler, der eine nicht leere Mailbox hat
• Die ‚Schauspieler‘ wird dann auf dem Testamentsvollstrecker
• läuft versandt Wo Nachrichten werden dequed und verarbeitet .
  • Wenn möglich, werden einige Nachrichten dequed und einer nach dem anderen verarbeitet
  • Nach der Verarbeitung einige Nachrichten (oder keine links), wird ein anderer Schauspieler gepflückt, Hunger zu verhindern. (throughput parameter)
• Aufstieg und wiederholen

Answer 3

Ich war mit diesem Thema für eine lange Zeit verwirrt. Ich nahm an, dass es eine Beziehung zwischen Threads und Schauspielern gibt. Für jeden Akteur gibt es einen Thread, der es hostet, also habe ich nachgedacht. Wahrscheinlich gibt es für jeden Thread mehrere Akteure, die im kooperativen Multitasking-Modus arbeiten.

Die Dokumentation konzentriert sich auf die Verwendung und deckt die interne Architektur leicht ab. Sie sollten nur Actor Klasse erweitern und Sie würden arbeiten Schauspieler. Also habe ich versucht zu erraten, wie das gemacht werden kann. Und stellte sich vor, dass jeder Actor Lebenszyklus hat. So etwas wie asynchrones Warten auf die Nachrichtenwarteschlange. Dann Nachricht verarbeiten. Gehe zum Anfang.

Das war völlig falsche Annahme. Obwohl die Dokumentation "Actor Life-Cycle" besagt, bedeutet dies nicht Actor Lebenszyklus. Actor erwähnt ist eine Konzeption eher als tatsächliche Objekt die Actor Klasse implementieren. Das Objekt befindet sich passiv im Java-Heap.

Um das Konzept in Einklang zu bringen, ist eine koordinierte Arbeit mit einer Menge echter Arbeiter erforderlich. Und das Herzstück ist Dispatcher. Es enthält alle Akteure, Threads und Nachrichten. Und wenn Ressourcen verfügbar werden und eine Nachricht zur Verarbeitung verfügbar ist, wird der Dispatcher aktiviert. Es dauert entsprechende Actor Objekt, Wraps seine Empfangs-Methode in Runnable und übergeben Sie es an einen Ersatz-Thread. Es gibt also keinen Lebenszyklus für das Objekt, nur gelegentliche Methodenaufrufe vom Aktorsystem.

Wenn Sie daran denken, macht es viel mehr Sinn als Schema ich früh angenommen. Aber es war schwierig für mich, es aus der verfügbaren Dokumentation abzuleiten.Es wurde von erfahrenen Concurrency-Programmierern geschrieben. Das Unterscheiden der Schauspielerklasse von Schauspieler Konzeption dahinter. Sie wissen, dass Dispatcher für ein Akteurs-System ist wie Task-Scheduler für ein Betriebssystem. So kommen sie schnell auf den Punkt und beschreiben verschiedene Geschmacksrichtungen und die Realisierung der für jedermann wohlbekannten Vorstellung.

Aber das ist nicht so einfach für einen Neuling. Er hat keine Bekanntschaft der Dispatcher Muster in Aktorsysteme Kontext. Ich habe versucht, "Dispatcher-Muster" zu googlen und es zeigte sich nur eine für einen Aktor nicht relevante Systemdefinition.

Ich habe leicht gefunden double dispatch, Multi-Versand und andere OOP Themen. Ich habe etwas ähnlich zu akka's Routern message dispatcher gefunden. Es gibt wahrscheinlich eine anständige Beschreibung für Nachrichten-Dispatcher, aber es ist nicht so einfach zu finden.

Ich hoffe, ich habe das Missverständnis behoben.