Implementacja modelu aktora

W informatyce implementacja modelu aktora dotyczy zagadnień implementacji modelu aktora .

Kosmiczny sześcian

Caltech Cosmic Cube został opracowany przez Chucka Seitza i in. w Caltech, zapewniając wsparcie architektoniczne dla systemów Actor. Znacząca różnica między Cosmic Cube a większością innych procesorów równoległych polega na tym, że ta maszyna z wieloma instrukcjami i wieloma danymi wykorzystuje przekazywanie komunikatów zamiast wspólnych zmiennych do komunikacji między współbieżnymi procesami. Ten model obliczeniowy znajduje odzwierciedlenie w strukturze sprzętu i systemie operacyjnym, a także jest jawną komunikacją przekazującą komunikaty widzianą przez programistę. Według Seitza [1985]:

Założeniem eksperymentu Cosmic Cube było, aby komunikacja między węzłami dobrze się skalowała do bardzo dużej liczby węzłów. Sieć bezpośrednia , taka jak hipersześcian, spełnia to wymaganie, zarówno pod względem zagregowanej przepustowości osiąganej w wielu jednoczesnych kanałach komunikacyjnych, jak i wykonalności implementacji. Hipersześcian jest w rzeczywistości rozproszonym wariantem pośredniej logarytmicznej sieci przełączającej, takiej jak sieci Omega lub Banyan : rodzaj, który może być używany w organizacjach współdzielonej pamięci masowej. Jednak w przypadku hipersześcianu ścieżki komunikacyjne przechodzą przez różną liczbę kanałów, a zatem wykazują różne opóźnienia. Możliwe jest zatem wykorzystanie lokalności komunikacyjnej przy umieszczaniu procesów w węzłach.

J-Maszyna

J -Machine została opracowana przez Billa Dally i in. w MIT, zapewniając wsparcie architektoniczne odpowiednie dla aktorów. Obejmuje to:

  • Wiadomości asynchroniczne
  • Jednolita przestrzeń adresów Aktora, do których wiadomości mogą być wysyłane jednocześnie, niezależnie od tego, czy odbiorca Aktor był lokalny czy nielokalny
  • Forma potokowania aktora (zobacz model aktora )

Concurrent Smalltalk (który można modelować za pomocą aktorów ) został opracowany do programowania J Machine.

Prototypowy język programowania aktorów

Hewitt [2006] przedstawił prototyp języka programowania Aktora w tym sensie, że bezpośrednio wyraża on ważne aspekty zachowania Aktorów. Komunikaty są wyrażane w formacie XML przy użyciu notacji :<tag>[<element> 1 ... <element>] for

„<”<znacznik>„>” <element> 1 ... <element> n „<”/<znacznik>„>”

Semantyka języka programowania jest definiowana poprzez zdefiniowanie każdej konstrukcji programu jako Aktora z własnym zachowaniem. Wykonanie jest modelowane przez przekazywanie komunikatów Eval między konstrukcjami programu podczas wykonywania.

Aktorzy środowiska

Każdy komunikat Eval ma adres Aktora, który działa jako środowisko z powiązaniami identyfikatorów programu. Aktorzy środowiska są niezmienni, tj. nie zmieniają się. Kiedy Żądanie[Powiąż[wartość identyfikatora] klient] jest odbierane przez Aktor Środowisko, tworzony jest nowy Aktor środowiska, tak że gdy nowy Aktor środowiska odbiera Żądanie[Wyszukaj[identyfikator'] klient'], to jeśli identyfikator jest taki sam jak identyfikator' wyślij klienta' Returned[value] , w przeciwnym razie wyślij Environment Request[Lookup[identifier'] customer'] . Powyższe opiera się na Actor EmptyEnvironment , które po otrzymaniu Request[Lookup[identifier] customer] wysyła do klienta Thrown[NotFound[identifier]] . Gdy otrzyma żądanie Bind, EmptyEnvironment działa jak powyższe środowisko .

Wyrażenia

Prototypowy język programowania ma wyrażenia następujących rodzajów:

<identyfikator>
Po odebraniu żądania[Eval[środowisko] klient] wyślij środowisko Request[Lookup[<identyfikator>] klient]
send <odbiorca> <komunikacja>
Po otrzymaniu żądania[Eval[środowisko] klient] wyślij <odbiorca> Request[Eval[environment] evalCustomer 1 ] gdzie evalCustomer 1 to nowy aktor, tak że
gdy evalCustomer 1 otrzyma komunikat Returned[theRecipient] , to wyślij <komunikacja>
Request[Eval[środowisko] evalCustomer 2 ] gdzie evalCustomer 2 to nowy aktor tak, że
kiedy evalCustomer 2 odbierze komunikat Returned[theCommunication] , wyśle ​​do odbiorcy komunikat .
<odbiorca>.<wiadomość>
Po odebraniu żądania[Eval[środowisko] klient] wyślij <odbiorca> Request[Eval[środowisko] evalKlient 1 ] tak, aby
po odebraniu przez evalKlienta 1 komunikatu Returned[theRecipient] , a następnie wyślij <message> Żądanie[Eval[środowisko] evalKlient 2 ] takie, że
gdy evalKlient 2 odbierze komunikat Returned[theMessage] , to wyślij Recipient
Request[theMessage klient]
odbiorca ... <wzorzec> i <wyrażenie> i ...
When Request[Eval[ environment] customer] zostanie odebrane, wyślij klientowi nowego aktora theReceiver tak, że
gdy odbiorca odbierze komunikację com , utwórz nowego bindingCustomer i wyślij środowisko
Request[Bind[<wzorzec> i com] bindingCustomer] i
jeśli bindingCustomer otrzyma Returned[environment” ] , wyślij <expression> i
Request[Eval[environment']]
w przeciwnym razie, jeśli bindingCustomer otrzyma Thrown[...] , spróbuj <pattern> i+1
zachowanie ... <wzorzec> i <wyrażenie> i ...
Po odebraniu żądania[Eval[środowisko] klient] wyślij klientowi nowego aktora theReceiver , tak aby
gdy odbiorca otrzyma Request[message customer'] , utwórz nowego wiążącego klienta i wyślij środowisko
Żądanie[bind[<wzór> i wiadomość] klient'] i
  1. jeśli bindingCustomer otrzyma Returned[environment'] , wyślij <expression> i
    Request[Eval[environment'] customer']
  2. w przeciwnym razie, jeśli bindingCustomer otrzyma Thrown[...] , spróbuj <pattern> i+1
{<wyrażenie> 1 , <wyrażenie> 2 }
Po otrzymaniu Request[Eval[środowisko] klient] wyślij <wyrażenie> 1 Request[Eval[środowisko]] i jednocześnie wyślij <wyrażenie> 2 Request[Eval[środowisko]] klient ] .
niech <identyfikator> = <wyrażenie> wartość w treści <wyrażenie>
Po otrzymaniu wiadomości [Eval[środowisko] klient] utwórz nowego evalCustomer i wyślij <wyrażenie> wartość
Request[Eval[środowisko] evalCustomer 1 .
Gdy evalCustomer otrzyma Returned[theValue] , utwórz nowego bindingCustomer i wyślij środowisko
Request[bind[<identifier> theValue] bindingCustomer]
Gdy bindingCustomer otrzyma Returned[environment'] , wyślij <expression> body Request[Eval[environment'] customer]
serializer <wyrażenie>
Po odebraniu żądania [Eval[środowisko] klient] wyślij klientowi Zwrócony [Serializer] , gdzie Serializator jest nowym aktorem, tak że komunikacja wysyłana do Serializatora jest przetwarzana w kolejności FIFO z aktorem zachowania, który początkowo jest <wyrażenie>. Eval[środowisko] i
Gdy komunikat com zostanie odebrany przez Serializer , wyślij zachowanie Aktor Żądanie [klient com'] , gdzie klient' jest nowym aktorem, tak że
gdy klient' otrzyma Returned[theNextBehavior], wtedy NextBehavior jest używany jako aktor zachowania dla następna komunikacja odebrana przez theSerializer .

Przykładowy program

Przykładowy program dla prostej komórki pamięci, która może zawierać dowolny adres Aktora, jest następujący:

Komórka ≡
odbiornik
Żądanie [Utwórz [początkowy] klient]
wyślij klienta Zwrócony [ serializator OdczytZapis(początkowy)]

Powyższy program, który tworzy komórkę pamięci, wykorzystuje zachowanie ReadWrite, które jest zdefiniowane w następujący sposób:

OdczytZapis(zawartość) ≡
zachowanie
Żądanie[odczyt[] klient]
{ wyślij klienta Zwrócony[treść], OdczytZapis(zawartość)}
Żądanie[zapis[x] klient]
{ wyślij klienta Zwrócony[], OdczytZapis(x)}

Zauważ, że powyższe zachowanie jest potokowe, tj. zachowanie może nadal przetwarzać poprzednią wiadomość odczytu lub zapisu, podczas gdy przetwarza następną wiadomość odczytu lub zapisu. Na przykład następujące wyrażenie tworzy komórkę x z początkową zawartością 5, a następnie jednocześnie zapisuje do niego wartości 7 i 9.

niech x = Cell.Create[5] w {x.write[7], x.write[9], x.read[]}

Wartość powyższego wyrażenia to 5, 7 lub 9.

Zobacz też

  • Henry Baker i Carl Hewitt Przyrostowe zbieranie śmieci procesów Proceedings of the Symposium on Artificial Intelligence Programming Languages. Zawiadomienia SIGPLAN 12, sierpień 1977.
  • Peter Bishop Bardzo duża przestrzeń adresowa Modułowo rozszerzalne systemy komputerowe MIT EECS Rozprawa doktorska. czerwiec 1977.
  • Henryk Baker. Systemy aktorów do obliczeń w czasie rzeczywistym Rozprawa doktorska MIT EECS. styczeń 1978.
  • Carla Hewitta i Russa Atkinsona. Specyfikacja i techniki sprawdzania serializatorów IEEE Journal on Software Engineering. styczeń 1979.
  • Kena Kahna. Obliczeniowa teoria animacji Rozprawa doktorska MIT EECS. sierpień 1979.
  • Carla Hewitta, Beppe Attardiego i Henry'ego Liebermana. Delegacja w obradach Message Passing of First International Conference on Distributed Systems Huntsville, AL. październik 1979.
  • Billa Kornfelda i Carla Hewitta. Metafora społeczności naukowej Transakcje IEEE dotyczące systemów, człowieka i cybernetyki . styczeń 1981.
  • Henryka Liebermana. Myślenie o wielu rzeczach naraz bez popadania w zakłopotanie: paralelizm w akcie 1 notatka MIT AI 626. maj 1981.
  • Henryka Liebermana. Zapowiedź Aktu 1 Notatka AI MIT 625. Czerwiec 1981.
  • Billa Kornfelda. Paralelizm w rozwiązywaniu problemów Rozprawa doktorska MIT EECS. sierpień 1981.
  • Daniela Theriaulta. Elementarz do notatki AI MIT Act-1 Language 672. Kwiecień 1982.
  • Henry'ego Liebermana i Carla Hewitta. Garbage Collector w czasie rzeczywistym na podstawie czasu życia obiektów CACM, czerwiec 1983 r.
  • Daniela Theriaulta. Problemy w projektowaniu i wdrażaniu aktu 2 Raport techniczny MIT AI 728. Czerwiec 1983.
  • Henryka Liebermana. Symulator obiektowy na konferencję pasieczną Amerykańskiego Stowarzyszenia Sztucznej Inteligencji, Waszyngton, DC, sierpień 1983.
  • Carla Hewitta i Henry'ego Liebermana. Zagadnienia projektowe w architekturze równoległej dla sztucznej inteligencji Notatka MIT AI 750. Listopad 1983.
  • Karola Seitza. Kosmiczna Kostka CACM. styczeń 1985 r.
  • Karola Manninga. Traveler: the Actor Observatory ECOOP 1987. Pojawia się także w Lecture Notes in Computer Science, tom. 276.
  • Carla Manninga. Acore: projekt podstawowego języka aktora i jego kompilacja pracy magisterskiej. MIT EECS. maj 1987.
  • William Athas i Charles Seitz Multicomputers: współbieżne komputery przekazujące wiadomości IEEE Computer, sierpień 1988.
  • William Athas i Nanette Boden Cantor: system programowania aktorów do obliczeń naukowych w materiałach warsztatów NSF dotyczących programowania współbieżnego obiektowego. 1988. Specjalne wydanie zawiadomień SIGPLAN.
  • Jeana-Pierre'a Briota. Od przedmiotów do aktorów: Studium ograniczonej symbiozy w Smalltalk-80 Rapport de Recherche 88-58, RXF-LITP, Paryż, Francja, wrzesień 1988
  • William Dally and Wills, D. Uniwersalne mechanizmy współbieżności PARLE '89.
  • W. Horwat, A. Chien i W. Dally. Doświadczenie z CST: programowanie i wdrażanie PLDI. 1989.
  • Akinori Yonezawa , wyd. ABCL: zorientowany obiektowo system współbieżny MIT Press. 1990.
  • Carla Hewitta i Gul Agha. Języki klauzul strzeżonego rogu: czy są dedukcyjne i logiczne? w sztucznej inteligencji na MIT, tom. 2. MIT Press 1991.
  • Carla Hewitta i Jeffa Inmana. DAI Betwixt i pomiędzy: od „inteligentnych agentów” do otwartych systemów naukowych Transakcje IEEE dotyczące systemów, człowieka i cybernetyki . listopad/grudzień 1991.
  • Williama Dally'ego i in. Procesor sterowany komunikatami: wielokomputerowy węzeł przetwarzający z wydajnymi mechanizmami IEEE Micro. kwiecień 1992.
  • Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen, Satish Thatte, Dave Winer. Prosty protokół dostępu do obiektów (SOAP) 1.1 Uwaga W3C. maj 2000.
  •   Edward A. Lee i Stephen Neuendorffer (czerwiec 2004). „Klasy i podklasy w projektowaniu zorientowanym na aktora”. doktorat Rozprawa - rozszerzone streszczenie. Konferencja na temat formalnych metod i modeli współprojektowania (MEMOCODE). CiteSeerX 10.1.1.9.6762 . {{ cite journal }} : Cite journal wymaga |journal= ( pomoc )
  • Carla Hewitta. Powtarzający się upadek programowania logicznego i dlaczego nastąpi reinkarnacja Co poszło nie tak i dlaczego: lekcje z badań i zastosowań sztucznej inteligencji. Raport techniczny SS-06-08. AAAI Press. marzec 2006.