Schauspielermodell - Actor model

Das Akteurmodell in der Informatik ist ein mathematisches Modell der gleichzeitigen Berechnung , das den Akteur als das universelle Primitiv der gleichzeitigen Berechnung behandelt. Als Reaktion auf eine empfangene Nachricht kann ein Akteur: lokale Entscheidungen treffen, weitere Akteure erstellen, mehr Nachrichten senden und bestimmen, wie auf die nächste empfangene Nachricht reagiert werden soll. Akteure können ihren eigenen privaten Status ändern , können sich jedoch nur indirekt durch Messaging beeinflussen (wodurch keine sperrenbasierte Synchronisierung erforderlich ist ).

Der Schauspieler Modell entstand im Jahr 1973. Es wird für ein sowohl als Rahmen verwendet theoretisches Verständnis der Berechnung und als theoretische Grundlage für mehrere praktischen Implementierungen von parallelen Systemen . Die Beziehung des Modells zu anderen Arbeiten wird in Akteursmodell- und Prozesskalkülen diskutiert .

Geschichte

Laut Carl Hewitt wurde das Aktormodell im Gegensatz zu früheren Rechenmodellen von der Physik inspiriert , einschließlich der allgemeinen Relativitätstheorie und der Quantenmechanik . Es wurde auch von den Programmiersprachen Lisp , Simula , frühen Versionen von Smalltalk , fähigkeitsbasierten Systemen und Paketvermittlung beeinflusst . Seine Entwicklung wurde "von der Aussicht auf hochparallele Rechenmaschinen motiviert, die aus Dutzenden, Hunderten oder sogar Tausenden von unabhängigen Mikroprozessoren bestehen, von denen jeder über einen eigenen lokalen Speicher und einen eigenen Kommunikationsprozessor verfügt und über ein Hochleistungskommunikationsnetz kommuniziert". Seit dieser Zeit die Einführung von massiver Parallelität durch Multi-Core und Manycore hat Computerarchitekturen Interesse an dem Schauspieler Modell wiederbelebt.

Nach der Publikation von Hewitt, Bishop und Steiger aus dem Jahr 1973 entwickelte Irene Greif im Rahmen ihrer Doktorarbeit eine operationale Semantik für das Akteursmodell. Zwei Jahre später veröffentlichten Henry Baker und Hewitt eine Reihe von axiomatischen Gesetzen für Aktorsysteme. Weitere wichtige Meilensteine ​​sind die Dissertation von William Clinger von 1981, die eine auf Machtdomänen basierende denotationale Semantik einführt, und die Dissertation von Gul Agha von 1985, in der ein übergangsbasiertes semantisches Modell komplementär zu Clingers weiterentwickelt wurde. Dies führte zur vollständigen Entwicklung der Akteursmodelltheorie .

Wesentliche Softwareimplementierungsarbeiten wurden von Russ Atkinson, Giuseppe Attardi, Henry Baker, Gerry Barber, Peter Bishop, Peter de Jong, Ken Kahn, Henry Lieberman, Carl Manning, Tom Reinhardt, Richard Steiger und Dan Theriault in der Message Passing Semantics Group durchgeführt Massachusetts Institute of Technology (MIT). Forschungsgruppen unter der Leitung von Chuck Seitz vom California Institute of Technology (Caltech) und Bill Dally vom MIT konstruierten Computerarchitekturen, die die Nachrichtenweitergabe im Modell weiterentwickelten. Siehe Actor-Modell-Implementierung .

Am California Institute of Technology , Kyoto University Tokoro Laboratory, Microelectronics and Computer Technology Corporation (MCC), MIT Artificial Intelligence Laboratory , SRI , Stanford University , University of Illinois at Urbana-Champaign , Pierre und Marie Curie University (University of Paris 6), University of Pisa , University of Tokyo Yonezawa Laboratory, Centrum Wiskunde & Informatica (CWI) und anderswo.

Grundsätzliche Konzepte

Das Schauspielermodell übernimmt die Philosophie, dass alles ein Schauspieler ist . Dies ist ähnlich wie bei der " Alles ist ein Objekt" -Philosophie, die von einigen objektorientierten Programmiersprachen verwendet wird.

Ein Akteur ist eine Recheneinheit, die als Reaktion auf eine empfangene Nachricht gleichzeitig:

  • eine endliche Anzahl von Nachrichten an andere Akteure senden;
  • eine endliche Anzahl neuer Akteure erstellen;
  • bestimmen das Verhalten, das für die nächste empfangene Nachricht verwendet werden soll.

Für die obigen Aktionen gibt es keine angenommene Reihenfolge und sie könnten parallel ausgeführt werden.

Die Entkopplung des Senders von der gesendeten Kommunikation war ein grundlegender Fortschritt des Akteurmodells, das asynchrone Kommunikations- und Kontrollstrukturen als Muster der Weitergabe von Nachrichten ermöglicht .

Die Empfänger von Nachrichten werden anhand ihrer Adresse identifiziert, die manchmal als "Postanschrift" bezeichnet wird. Somit kann ein Akteur nur mit Akteuren kommunizieren, deren Adressen er besitzt. Es kann diese aus einer empfangenen Nachricht erhalten oder wenn die Adresse für einen Akteur ist, den er selbst erstellt hat.

Das Akteurmodell zeichnet sich durch inhärente Parallelität der Berechnung innerhalb und zwischen Akteuren, dynamische Erzeugung von Akteuren, Einbeziehung von Akteuradressen in Nachrichten und Interaktion nur durch direkte asynchrone Nachrichtenweitergabe ohne Einschränkung der Nachrichteneingangsreihenfolge aus.

Formale Systeme

Im Laufe der Jahre wurden mehrere unterschiedliche formale Systeme entwickelt, die eine Argumentation über Systeme im Akteursmodell ermöglichen. Diese beinhalten:

Es gibt auch Formalismen, die dem Akteursmodell nicht ganz treu sind, da sie die garantierte Übermittlung von Nachrichten nicht formalisieren, einschließlich der folgenden (siehe Versuche, Akteursemantik mit Algebra und linearer Logik in Beziehung zu setzen ):

Anwendungen

Das Akteursmodell kann als Rahmen für die Modellierung, das Verständnis und die Argumentation über eine Vielzahl von gleichzeitigen Systemen verwendet werden . Zum Beispiel:

  • Elektronische Post ( E-Mail ) kann als Akteursystem modelliert werden. Accounts werden als Akteure und E-Mail-Adressen als Akteuradressen modelliert .
  • Webdienste können mit SOAP- Endpunkten (Simple Object Access Protocol ) modelliert werden, die als Akteuradressen modelliert werden.
  • Objekte mit Sperren ( zB in Java und C# ) können als Serialisierer modelliert werden , sofern ihre Implementierungen so sind , dass Nachrichten kontinuierlich ankommen können ( etwa indem sie in einer internen Warteschlange gespeichert werden ). Ein Serializer ist eine wichtige Art von Akteur, der durch die Eigenschaft definiert wird, dass er ständig für neue Nachrichten verfügbar ist; jede an einen Serializer gesendete Nachricht wird garantiert ankommen.
  • Testing and Test Control Notation ( TTCN ), sowohl TTCN-2 als auch TTCN-3 , folgt dem Schauspielermodell ziemlich genau. In TTCN ist Aktor eine Testkomponente: entweder Paralleltestkomponente (PTC) oder Haupttestkomponente (MTC). Testkomponenten können Nachrichten an und von entfernten Partnern (Peer-Testkomponenten oder Testsystemschnittstelle) senden und empfangen, wobei letztere durch ihre Adresse identifiziert werden. An jede Testkomponente ist ein Verhaltensbaum gebunden; Testkomponenten laufen parallel und können dynamisch von übergeordneten Testkomponenten erstellt werden. Integrierte Sprachkonstrukte ermöglichen die Definition von Aktionen, die ausgeführt werden, wenn eine erwartete Nachricht aus der internen Nachrichtenwarteschlange empfangen wird, wie das Senden einer Nachricht an eine andere Peer-Entität oder das Erstellen neuer Testkomponenten.

Message-Passing-Semantik

Beim Akteurmodell geht es um die Semantik der Nachrichtenweitergabe .

Unbegrenzte Nichtdeterminismus-Kontroverse

Die ersten nebenläufigen Programme waren wohl Interrupt-Handler . Während seines normalen Betriebs musste ein Computer in der Lage sein, Informationen von außen (Zeichen von einer Tastatur, Pakete von einem Netzwerk usw. ) zu empfangen . Als die Informationen ankamen, wurde die Ausführung des Computers unterbrochen und ein spezieller Code (ein sogenannter Interrupt-Handler) aufgerufen, um die Informationen in einen Datenpuffer zu legen, wo sie anschließend abgerufen werden konnten.

In den frühen 1960er Jahren wurden Interrupts verwendet, um die gleichzeitige Ausführung mehrerer Programme auf einem Prozessor zu simulieren. Die Parallelität mit gemeinsam genutztem Speicher führte zu dem Problem der Parallelitätssteuerung . Ursprünglich wurde dieses Problem als ein Problem des gegenseitigen Ausschlusses auf einem einzigen Computer konzipiert. Edsger Dijkstra entwickelte Semaphore und später, zwischen 1971 und 1973, Tony Hoare und Per Brinch Hansen entwickelt überwacht die gegenseitige Ausgrenzung Problem zu lösen. Keine dieser Lösungen stellte jedoch ein Programmiersprachenkonstrukt bereit, das den Zugriff auf gemeinsam genutzte Ressourcen kapselte. Diese Einkapselung wurde später durch das Serializer- Konstrukt erreicht ([Hewitt und Atkinson 1977, 1979] und [Atkinson 1980]).

Die ersten Modelle der Berechnung ( zB , Turingmaschinen , Postproduktionen, die Lambda - Kalkül , usw. ) wurden auf Mathematik basiert und die Verwendung eines globalen Zustand einen Rechen darzustellen Schritt (später verallgemeinert in [McCarthy und Hayes 1969] und [Dijkstra 1976] siehe Ereignisordnungen versus globaler Zustand ). Jeder Rechenschritt ging von einem globalen Zustand der Berechnung zum nächsten globalen Zustand. Der globale Zustandsansatz wurde in der Automatentheorie für endliche Automaten und Push-down- Stack-Maschinen einschließlich ihrer nichtdeterministischen Versionen fortgesetzt . Solche nichtdeterministischen Automaten haben die Eigenschaft des beschränkten Nichtdeterminismus ; das heißt, wenn eine Maschine immer anhält, wenn sie in ihrem Anfangszustand gestartet wird, dann gibt es eine Grenze für die Anzahl der Zustände, in denen sie anhält.

Edsger Dijkstra hat den nichtdeterministischen Global-State-Ansatz weiterentwickelt. Das Modell von Dijkstra führte zu einer Kontroverse über den unbegrenzten Nichtdeterminismus (auch als unbegrenzte Unbestimmtheit bezeichnet ), eine Eigenschaft der Nebenläufigkeit, durch die die Verzögerung bei der Bearbeitung einer Anfrage als Ergebnis einer Streitschlichtung um gemeinsame Ressourcen unbegrenzt werden kann, während gleichzeitig garantiert wird, dass die Anfrage wird schließlich bedient . Hewitt argumentierte, dass das Schauspielermodell die Servicegarantie bieten sollte. In Dijkstras Modell konnte ein (paralleles) Programm, das in einem wohldefinierten Zustand gestartet wurde, nur in einer begrenzten Anzahl von Zuständen enden, obwohl zwischen der Ausführung sequentieller Befehle auf einem Computer eine unbegrenzte Zeit liegen könnte [Dijkstra 1976]. Folglich konnte sein Modell die Servicegarantie nicht bieten. Dijkstra argumentierte, dass es unmöglich sei, unbegrenzten Nichtdeterminismus zu implementieren.

Hewitt argumentierte anders: Es gibt keine Grenze, die festgelegt werden kann, wie lange eine Rechenschaltung namens Arbiter braucht, um sich einzupendeln (siehe Metastabilität (Elektronik) ). Arbiter werden in Computern mit dem Umstand zu tun , dass Computeruhr asynchron zum Eingang von außen arbeiten, zB , Tastatureingabe, Festplattenzugriff, Netzeingang, usw. So ist es eine unbegrenzte Zeit für eine Nachricht an einen Computer gesendet nehmen könnte empfangen werden und der Computer zwischenzeitlich eine unbegrenzte Anzahl von Zuständen durchlaufen kann.

Das Schauspieler - Modell verfügt über unbegrenzten Nicht - Determinismus , die in einem mathematischen Modell von gefangen genommen wurden Will Clinger mit Domain - Theorie . Im Akteurmodell gibt es keinen globalen Zustand.

Direkte Kommunikation und Asynchronität

Nachrichten im Akteurmodell werden nicht unbedingt gepuffert. Dies war ein scharfer Bruch mit früheren Ansätzen für Modelle der gleichzeitigen Berechnung. Die fehlende Pufferung sorgte bei der Entwicklung des Akteurmodells für große Missverständnisse und ist bis heute umstritten. Einige Forscher argumentierten, dass die Nachrichten im "Äther" oder in der "Umgebung" gepuffert werden. Außerdem werden Nachrichten im Akteurmodell einfach gesendet (wie Pakete in IP ); ein synchroner Handshake mit dem Empfänger ist nicht erforderlich.

Akteurserstellung plus Adressen in Nachrichten bedeutet variable Topologie

Eine natürliche Entwicklung des Akteurmodells war, Adressen in Nachrichten zuzulassen. Beeinflusst durch paketvermittelte Netzwerke [1961 und 1964] schlug Hewitt die Entwicklung eines neuen Modells der gleichzeitigen Berechnung vor, bei dem Kommunikationen überhaupt keine erforderlichen Felder haben würden: sie könnten leer sein. Wenn der Absender einer Mitteilung wünschte, dass ein Empfänger Zugriff auf Adressen hat, die der Empfänger noch nicht hatte, müsste die Adresse natürlich in der Mitteilung mitgesendet werden.

Beispielsweise muss ein Akteur möglicherweise eine Nachricht an einen empfangenden Akteur senden, von dem er später eine Antwort erwartet, aber die Antwort wird tatsächlich von einer dritten Akteurkomponente verarbeitet, die für den Empfang und die Verarbeitung der Antwort konfiguriert wurde (z , ein anderer Akteur, der das Beobachtermuster implementiert ). Der ursprüngliche Akteur könnte dies erreichen, indem er eine Mitteilung sendet, die die Nachricht enthält, die er senden möchte, zusammen mit der Adresse des dritten Akteurs, der die Antwort bearbeitet. Dieser dritte Akteur, der die Antwort handhabt, wird als Wiederaufnahme bezeichnet (manchmal auch als Fortsetzungs- oder Stapelrahmen bezeichnet ). Wenn der Empfänger-Akteur bereit ist, eine Antwort zu senden, sendet er die Antwortnachricht an die Adresse des Wiederaufnahme- Akteurs, die in der ursprünglichen Kommunikation enthalten war.

Die Fähigkeit von Akteuren, neue Akteure zu schaffen, mit denen sie Kommunikationen austauschen können, zusammen mit der Fähigkeit, die Adressen anderer Akteure in Nachrichten aufzunehmen, gibt Akteuren also die Möglichkeit, beliebig variable topologische Beziehungen untereinander aufzubauen und daran teilzunehmen, ähnlich wie die Objekte in Simula und anderen objektorientierten Sprachen können auch relational zu variablen Topologien von Nachrichtenaustauschobjekten zusammengesetzt werden.

Von Natur aus gleichzeitig

Im Gegensatz zum bisherigen Ansatz, der auf der Komposition sequenzieller Prozesse basiert, wurde das Akteursmodell als inhärent nebenläufiges Modell entwickelt. In dem Schauspieler Modell Sequentialität war ein Sonderfall, der von gleichzeitiger Berechnung abgeleitet , wie in erläuterten Schauspieler Modelltheorie .

Keine Anforderung an die Reihenfolge des Nachrichteneingangs

Hewitt sprach sich dagegen aus, die Anforderung hinzuzufügen, dass Nachrichten in der Reihenfolge ankommen müssen, in der sie an den Akteur gesendet werden. Wenn eine Reihenfolge der Ausgabenachrichten gewünscht wird, kann sie von einem Warteschlangenakteur modelliert werden, der diese Funktionalität bereitstellt. Ein solcher Warteschlangenakteur würde die ankommenden Nachrichten in eine Warteschlange stellen, damit sie in FIFO- Reihenfolge abgerufen werden könnten . Wenn also ein Akteur Xeine Nachricht M1an einen Akteur Yund später Xeine weitere Nachricht M2an sendet Y, gibt es keine Anforderung, die vorher M1eintrifft . YM2

In dieser Hinsicht spiegelt das Aktormodell Paketvermittlungssysteme , die nicht garantieren, dass Pakete in der gesendeten Reihenfolge empfangen werden müssen. Die Nichtbereitstellung der Lieferreihenfolge-Garantie ermöglicht die Paketvermittlung, um Pakete zu puffern, mehrere Pfade zum Senden von Paketen zu verwenden, beschädigte Pakete erneut zu senden und andere Optimierungen bereitzustellen.

Beispielsweise ist es Akteuren erlaubt, die Verarbeitung von Nachrichten in einer Pipeline zu verarbeiten. Dies bedeutet, dass M1ein Akteur während der Verarbeitung einer Nachricht das Verhalten festlegen kann, mit dem die nächste Nachricht verarbeitet wird, und dann tatsächlich mit der Verarbeitung einer anderen Nachricht beginnen, M2bevor die Verarbeitung abgeschlossen ist M1. Nur weil ein Schauspieler Pipeline erlaubt die Verarbeitung von Nachrichten bedeutet nicht , dass es muss Pipeline die Verarbeitung. Ob eine Nachricht weitergeleitet wird, ist ein technischer Kompromiss. Wie würde ein externer Beobachter wissen, ob die Verarbeitung einer Nachricht durch einen Akteur eine Pipeline hat? Es gibt keine Mehrdeutigkeit in der Definition eines Akteurs, die durch die Möglichkeit des Pipelinings entsteht. Natürlich ist es bei einigen Implementierungen möglich, die Pipeline-Optimierung falsch durchzuführen, wobei in diesem Fall ein unerwartetes Verhalten auftreten kann.

Lokalität

Ein weiteres wichtiges Merkmal des Akteursmodells ist die Lokalität.

Lokalität bedeutet, dass ein Akteur bei der Verarbeitung einer Nachricht Nachrichten nur an Adressen senden kann, die er in der Nachricht empfängt, an Adressen, die er bereits vor dem Empfang der Nachricht hatte, und an Adressen für Akteure, die er während der Verarbeitung der Nachricht erstellt. (Aber siehe Adressen von Akteuren synthetisieren .)

Lokalität bedeutet auch, dass keine gleichzeitige Änderung an mehreren Standorten stattfindet. Auf diese Weise unterscheidet es sich von einigen anderen Gleichzeitigkeitsmodellen, zB dem Petrinetzmodell , bei dem Token gleichzeitig von mehreren Orten entfernt und an anderen Orten platziert werden.

Aktorsysteme komponieren

Die Idee, Akteursysteme zu größeren zusammenzusetzen, ist ein wichtiger Aspekt der Modularität , der in Gul Aghas Doktorarbeit entwickelt wurde, die später von Gul Agha, Ian Mason, Scott Smith und Carolyn Talcott entwickelt wurde .

Verhaltensweisen

Eine wichtige Neuerung war die Einführung eines Verhaltens, das als mathematische Funktion spezifiziert wurde, um auszudrücken, was ein Akteur tut, wenn er eine Nachricht verarbeitet, einschließlich der Spezifikation eines neuen Verhaltens, um die nächste eintreffende Nachricht zu verarbeiten. Verhaltensweisen stellten einen Mechanismus bereit, um die gemeinsame Nutzung in Parallelität mathematisch zu modellieren.

Behaviors befreite das Actor-Modell auch von Implementierungsdetails, z. B. dem Smalltalk-72-Token-Stream-Interpreter. Es ist jedoch wichtig zu verstehen, dass die effiziente Implementierung von Systemen, die durch das Aktormodell beschrieben werden, eine umfassende Optimierung erfordert . Weitere Informationen finden Sie unter Actor-Modell-Implementierung .

Modellierung anderer Nebenläufigkeitssysteme

Andere concurrency Systeme ( zB , Prozess calculi ) kann in dem Schauspieler Modell unter Verwendung eines modelliert wird Commit-Protokoll .

Theorem der computergestützten Darstellung

Es gibt ein Computational Representation Theorem im Aktormodell für Systeme, die in dem Sinne geschlossen sind, dass sie keine Kommunikation von außen erhalten. Die mathematische Bezeichnung eines geschlossenen Systems besteht aus einem Anfangsverhalten und einer verhaltensnähenden Funktion . Diese erhalten immer bessere Näherungen und konstruieren eine Denotation (Bedeutung) für [Hewitt 2008; Clinger 1981]: SprogressionS

Auf diese Weise Skann mathematisch in Bezug auf alle seine möglichen Verhaltensweisen (einschließlich derjenigen mit unbegrenztem Nichtdeterminismus) charakterisiert werden. Obwohl es keine Implementierung von ist , kann es verwendet werden, um eine Verallgemeinerung der Church-Turing-Rosser-Kleene-These [Kleene 1943] zu beweisen:

Eine Folge des obigen Theorems ist, dass ein endlicher Akteur nichtdeterministisch mit einer unzählbaren Anzahl verschiedener Ausgaben antworten kann .

Beziehung zur Logikprogrammierung

Eine der Hauptmotivationen für die Entwicklung des Akteurmodells war das Verständnis und der Umgang mit den Kontrollstrukturproblemen, die bei der Entwicklung der Programmiersprache Planner auftraten . Nachdem das Akteursmodell zunächst definiert war, bestand eine wichtige Herausforderung darin, die Aussagekraft des Modells im Verhältnis zu Robert Kowalskis These zu verstehen, dass "Rechen durch Deduktion subsumiert werden kann". Hewitt argumentierte, dass sich Kowalskis These für die nebenläufige Berechnung im Akteurmodell als falsch herausstellte (siehe Unbestimmtheit in der nebenläufigen Berechnung ).

Nichtsdestotrotz wurden Versuche unternommen, die Logikprogrammierung auf die gleichzeitige Berechnung auszudehnen . Hewitt und Agha [1991] behaupteten jedoch, dass die resultierenden Systeme in folgendem Sinne nicht deduktiv waren: Rechenschritte der nebenläufigen Logikprogrammiersysteme folgen nicht deduktiv auf vorherige Schritte (siehe Unbestimmtheit in der nebenläufigen Berechnung ). In letzter Zeit wurde die logische Programmierung so in das Akteursmodell integriert, dass die logische Semantik erhalten bleibt.

Migration

Migration im Akteurmodell ist die Fähigkeit von Akteuren, den Standort zu wechseln. ZB hat Aki Yonezawa in seiner Dissertation ein Postamt modelliert, das Kundenakteure betreten, während des Betriebs den Standort wechseln und wieder verlassen können. Ein Akteur, der migriert werden kann, kann durch einen Standortakteur modelliert werden, der sich ändert, wenn der Akteur migriert. Die Richtigkeit dieser Modellierung ist jedoch umstritten und Gegenstand der Forschung.

Sicherheit

Die Sicherheit von Akteuren kann wie folgt geschützt werden:

Adressen von Akteuren synthetisieren

Ein heikler Punkt im Akteurmodell ist die Fähigkeit, die Adresse eines Akteurs zu synthetisieren. In einigen Fällen kann Sicherheit verwendet werden, um die Synthese von Adressen zu verhindern (siehe Sicherheit ). Wenn jedoch eine Akteuradresse einfach eine Bitfolge ist, kann sie eindeutig synthetisiert werden, obwohl es schwierig oder sogar unmöglich sein kann, die Adresse eines Akteurs zu erraten, wenn die Bitfolgen lang genug sind. SOAP verwendet eine URL für die Adresse eines Endpunkts, an dem ein Akteur erreicht werden kann. Da es sich bei einer URL um eine Zeichenkette handelt, kann sie eindeutig synthetisiert werden, obwohl sie durch Verschlüsselung praktisch unmöglich zu erraten ist.

Die Synthese der Adressen von Akteuren wird in der Regel durch Mapping modelliert. Die Idee ist, ein Akteursystem zu verwenden, um die Zuordnung zu den tatsächlichen Akteuradressen durchzuführen. Beispielsweise kann auf einem Computer die Speicherstruktur des Computers als Akteursystem modelliert werden, das das Mapping durchführt. Im Fall von SOAP- Adressen modelliert es das DNS und den Rest der URL- Zuordnung.

Im Gegensatz zu anderen Modellen der Parallelität bei der Nachrichtenweitergabe

Robin Milners erste veröffentlichte Arbeit zur Nebenläufigkeit war auch insofern bemerkenswert, als sie nicht auf der Komposition sequentieller Prozesse beruhte. Seine Arbeit unterschied sich vom Akteurmodell, weil es auf einer festen Anzahl von Prozessen fester Topologie basierte, die Zahlen und Zeichenfolgen unter Verwendung synchroner Kommunikation kommunizierten. Das ursprüngliche von Tony Hoare veröffentlichte Modell der kommunizierenden sequentiellen Prozesse (CSP) unterschied sich vom Akteur-Modell, da es auf der parallelen Zusammenstellung einer festen Anzahl von sequentiellen Prozessen, die in einer festen Topologie verbunden sind, und der Kommunikation über synchrone Nachrichtenweitergabe basierend auf Prozessnamen basierte (Siehe Akteursmodell und Prozesskalkülhistorie ). Spätere Versionen von CSP gaben die Kommunikation auf der Grundlage von Prozessnamen zugunsten der anonymen Kommunikation über Kanäle auf, ein Ansatz, der auch in Milners Arbeiten über die Berechnung von kommunizierenden Systemen und den π-Kalkül verwendet wird .

Diese frühen Modelle von Milner und Hoare hatten beide die Eigenschaft des beschränkten Nichtdeterminismus. Modernes, theoretisches CSP ([Hoare 1985] und [Roscoe 2005]) bietet explizit unbegrenzten Nichtdeterminismus.

Petrinetze und ihre Erweiterungen (z. B. farbige Petrinetze) sind insofern wie Akteure, als sie auf asynchroner Nachrichtenweitergabe und unbegrenztem Nichtdeterminismus basieren, während sie wie frühe CSPs darin bestehen, dass sie feste Topologien elementarer Verarbeitungsschritte (Übergänge) und Nachrichtenspeicher definieren (setzt).

Beeinflussen

Das Akteursmodell hat sowohl die Theorieentwicklung als auch die praktische Softwareentwicklung beeinflusst.

Theorie

Das Akteursmodell hat die Entwicklung des π-Kalküls und der nachfolgenden Prozesskalküle beeinflusst . Robin Milner schrieb in seinem Turing-Vortrag:

Jetzt besteht der reine Lambda-Kalkül nur aus zwei Arten von Dingen: Termen und Variablen. Können wir die gleiche Wirtschaftlichkeit für eine Prozessrechnung erreichen? Carl Hewitt hat mit seinem Schauspielermodell längst auf diese Herausforderung reagiert; er erklärte, dass ein Wert, ein Operator für Werte und ein Prozess alle dasselbe sein sollten: ein Akteur.

Dieses Ziel beeindruckte mich, weil es die Homogenität und Vollständigkeit des Ausdrucks impliziert ... Aber es dauerte lange, bis ich sah, wie ich das Ziel algebraisch erreichen konnte ...

Im Sinne von Hewitt besteht unser erster Schritt darin, zu fordern, dass alle Dinge, die mit Begriffen bezeichnet oder mit Namen zugänglich sind – Werte, Register, Operatoren, Prozesse, Objekte – alle von der gleichen Art sind; sie sollten alle Prozesse sein.

Üben

Das Akteursmodell hat weitreichenden Einfluss auf die Handelspraxis gehabt. Zum Beispiel hat Twitter Schauspieler für die Skalierbarkeit verwendet. Außerdem hat Microsoft das Akteurmodell bei der Entwicklung seiner Bibliothek für asynchrone Agenten verwendet. Es gibt viele andere Akteurbibliotheken, die im Abschnitt Akteurbibliotheken und Frameworks unten aufgeführt sind.

Behobene Probleme

Laut Hewitt [2006] befasst sich das Akteursmodell mit Fragen der Computer- und Kommunikationsarchitektur, simultanen Programmiersprachen und Webdiensten, einschließlich der folgenden:

  • Skalierbarkeit : die Herausforderung, die Parallelität sowohl lokal als auch nicht lokal hochzuskalieren.
  • Transparenz : Überbrückung der Kluft zwischen lokaler und nicht-lokaler Parallelität. Transparenz ist derzeit ein umstrittenes Thema. Einige Forscher haben sich für eine strikte Trennung zwischen lokaler Parallelität mit gleichzeitigen Programmiersprachen (zB Java und C# ) und nicht- lokaler Parallelität mit SOAP für Webdienste ausgesprochen . Eine strikte Trennung erzeugt einen Mangel an Transparenz, der Probleme verursacht, wenn ein Wechsel zwischen lokalem und nicht-lokalem Zugriff auf Webdienste erwünscht/notwendig ist (siehe Distributed Computing ).
  • Inkonsistenz : Inkonsistenz ist die Norm, da alle sehr großen Wissenssysteme über die Interaktionen zwischen menschlichen Informationssystemen inkonsistent sind. Diese Inkonsistenz erstreckt sich auch auf die Dokumentation und Spezifikationen sehr großer Systeme (zB Microsoft Windows Software etc.), die intern inkonsistent sind.

Viele der im Aktormodell eingeführten Ideen finden aus den gleichen Gründen mittlerweile auch Anwendung in Multiagentensystemen [Hewitt 2006b 2007b]. Der Hauptunterschied besteht darin, dass Agentensysteme (in den meisten Definitionen) den Akteuren zusätzliche Beschränkungen auferlegen, die typischerweise erfordern, dass sie Verpflichtungen und Ziele verwenden.

Programmierung mit Schauspielern

Eine Reihe verschiedener Programmiersprachen verwenden das Akteurmodell oder eine Variation davon. Zu diesen Sprachen gehören:

Frühe Programmiersprachen für Schauspieler

  • Akt 1, 2 und 3
  • Acttalk
  • Ani
  • Kantor
  • Rosette

Spätere Programmiersprachen für Schauspieler

Akteurbibliotheken und Frameworks

Akteurbibliotheken oder -frameworks wurden ebenfalls implementiert, um eine Programmierung im Akteurstil in Sprachen zu ermöglichen, die keine integrierten Akteure haben. Einige dieser Frameworks sind:

Name Status Neueste Erscheinung Lizenz Sprachen
Reagiert Aktiv 2021-09-05 Apache 2.0 Java
Schauspieler Aktiv 2020-04-16 Apache-2.0 / MIT Rost
Bastion Aktiv 2020-08-12 Apache-2.0 / MIT Rost
Actix Aktiv 2020-09-11 MIT Rost
Aojet Aktiv 2016-10-17 MIT Schnell
Schauspieler Aktiv 2017-03-09 MIT Java
Schauspieler4j Aktiv 31.01.2020 Apache 2.0 Java
Schauspieler Aktiv 2019-04-09 Apache 2.0 Java
Vert.x Aktiv 2018-02-13 Apache 2.0 Java, Groovy, Javascript, Ruby, Scala, Kotlin, Ceylon
SchauspielerFx Inaktiv 2013-11-13 Apache 2.0 .NETZ
Akka (Werkzeugkasten) Aktiv 2019-05-21 Apache 2.0 Java und Scala
Akka.NET Aktiv 2020-08-20 Apache 2.0 .NETZ
Remact.Net Inaktiv 2016-06-26 MIT .NET, Javascript
Ateji PX Inaktiv ? ? Java
czmq Aktiv 2016-11-10 MPL-2 C
F# MailboxProzessor Aktiv wie F# (integrierte Kernbibliothek) Apache-Lizenz F#
Korus Aktiv 2010-02-04 GPL 3 Java
Kelim Aktiv 2018-11-09 MIT Java
ActorFoundry (nach Kelim) Inaktiv 2008-12-28 ? Java
SchauspielerKit Aktiv 2011-09-13 BSD Ziel c
Cloud Haskell Aktiv 2015-06-17 BSD Haskell
CloudI Aktiv 2021-05-27 MIT ATS, C/C++, Elixir/Erlang/LFE, Go, Haskell, Java, Javascript, OCaml, Perl, PHP, Python, Ruby
Unordnung Aktiv 2017-05-12 LGPL 2.1 C, C++ (cluttermm), Python (pyclutter), Perl (perl-Clutter)
NAct Inaktiv 2012-02-28 LGPL 3.0 .NETZ
Nact Aktiv 2018-06-06 Apache 2.0 JavaScript/ReasonML
Retlang Inaktiv 2011-05-18 Neue BSD .NETZ
JSchauspieler Inaktiv 2013-01-22 LGPL Java
Jetlang Aktiv 2013-05-30 Neue BSD Java
Haskell-Schauspieler Aktiv? 2008 Neue BSD Haskell
GPar Aktiv 2014-05-09 Apache 2.0 Groovig
OOSMOS Aktiv 2019-05-09 GPL 2.0 und kommerziell (doppelte Lizenzierung) C. C++-freundlich
Panini Aktiv 2014-05-22 MPL 1.1 Programmiersprache an sich
VERHANDELN Aktiv? 2007-22-07 GPL 2.1 Python
Peernetisch Aktiv 2007-06-29 LGPL 3.0 Java
Picos Aktiv 2020-02-04 MIT KRL
PostSharp Aktiv 2014-09-24 Kommerziell / Freemium .NETZ
Pulsar Aktiv 2016-07-09 Neue BSD Python
Pulsar Aktiv 2016-02-18 LGPL / Eclipse Clojure
Pykka Aktiv 2019-05-07 Apache 2.0 Python
Termitenschema Aktiv? 2009-05-21 LGPL Schema (Gambit-Implementierung)
Theron Inaktiv 2014-01-18 MIT C++
Thespian Aktiv 2020-03-10 MIT Python
Quasar Aktiv 2018-11-02 LGPL / Eclipse Java
Befreier Aktiv? 2009 GPL 2.0 C
Schauspieler-CPP Aktiv 2012-03-10 GPL 2.0 C++
S4 Inaktiv 2012-07-31 Apache 2.0 Java
C++-Akteur-Framework (CAF) Aktiv 2020-02-08 Boost-Softwarelizenz 1.0 und BSD 3-Klausel C++11
Zelluloid Aktiv 2018-12-20 MIT Rubin
LabVIEW Actor Framework Aktiv 2012-03-01 National Instruments SLA LabVIEW
LabVIEW Messenger-Bibliothek Aktiv 2021-05-24 BSD LabVIEW
Orbit Aktiv 2019-05-28 Neue BSD Java
QP-Frameworks für eingebettete Echtzeitsysteme Aktiv 2019-05-25 GPL 2.0 und kommerziell (doppelte Lizenzierung) C und C++
libprocess Aktiv 2013-06-19 Apache 2.0 C++
SObjectizer Aktiv 2020-05-09 Neue BSD C++11
Rotor Aktiv 2020-10-23 MIT-Lizenz C++17
Orleans Aktiv 2021-09-03 MIT-Lizenz C#/.NET
Skynet Aktiv 2020-12-10 MIT-Lizenz C/Lua
Reaktoren.IO Aktiv 2016-06-14 BSD-Lizenz Java/Scala
libagens Aktiv 2020-03-08 Kostenlose Softwarelizenz C++11
Proto.Schauspieler Aktiv 2021-01-05 Kostenlose Softwarelizenz Go, C#, Python, JavaScript, Java, Kotlin
FunktionalJava Aktiv 2018-08-18 BSD 3-Klausel Java
Riker Aktiv 2019-01-04 MIT-Lizenz Rost
Komödie Aktiv 2019-03-09 EPL 1.0 JavaScript
vlingo Aktiv 2020-07-26 Öffentliche Mozilla-Lizenz 2.0 Java, Kotlin, bald .NET
wasmCloud Aktiv 2021-03-23 Apache 2.0 WebAssembly (Rust, TinyGo, Zig, AssemblyScript)
Strahl Aktiv 2020-08-27 Apache 2.0 Python

Siehe auch

Verweise

Weiterlesen

Externe Links

  • Hewitt, Meijer und Szyperski: The Actor Model (alles, was Sie wissen wollten, aber nicht zu fragen wagten) Microsoft Channel 9. 9. April 2012.
  • Functional Java – eine Java-Bibliothek, die eine Implementierung nebenläufiger Akteure mit Codebeispielen im Standard-Java- und Java 7 BGGA-Stil enthält.
  • ActorFoundry – eine Java-basierte Bibliothek für die Schauspielerprogrammierung. Die bekannte Java-Syntax, eine Ant-Build-Datei und eine Reihe von Beispielen machen die Einstiegsbarriere sehr niedrig.
  • ActiveJava – ein Prototyp der Java-Spracherweiterung für die Schauspielerprogrammierung.
  • Akka – schauspielerbasierte Bibliothek in Scala und Java, von Lightbend Inc. .
  • GPars – eine Parallelitätsbibliothek für Apache Groovy und Java
  • Bibliothek für asynchrone Agenten – Microsoft-Akteurbibliothek für Visual C++. „Die Agentenbibliothek ist eine C++-Vorlagenbibliothek, die ein akteurbasiertes Programmiermodell und die prozessinterne Nachrichtenweitergabe für grobkörnige Datenfluss- und Pipeline-Aufgaben fördert.“
  • ActorThread in C++11 – Basistemplate, das den Kern des Actor-Modells über nackte Threads in Standard-C++11 bereitstellt