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
-
jeśli bindingCustomer otrzyma Returned[environment'] , wyślij <expression> i
- Request[Eval[environment'] customer']
- w przeciwnym razie, jeśli bindingCustomer otrzyma Thrown[...] , spróbuj <pattern> i+1
-
jeśli bindingCustomer otrzyma Returned[environment'] , wyślij <expression> i
- {<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)]
- Żądanie [Utwórz [początkowy] klient]
-
odbiornik
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)}
- Żądanie[odczyt[] klient]
-
zachowanie
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.