Реализация модели актера
Эта статья включает список литературы , связанную литературу или внешние ссылки , но ее источники остаются неясными, поскольку в ней отсутствуют встроенные цитаты . ( Август 2023 г. ) |
В информатике касается реализация модели Актера вопросов реализации модели Актера .
Космический Куб
[ редактировать ]Космический куб Калифорнийского технологического института был разработан Чаком Зейтцем и др. в Калифорнийском технологическом институте обеспечивает архитектурную поддержку систем Actor. Существенная разница между Космическим Кубом иБольшинство других параллельных процессоров заключается в том, что эта множественная инструкциямашина с несколькими данными использует передачу сообщенийвместо общих переменных для связи междупараллельные процессы. Эта вычислительная модель отраженав аппаратной структуре и операционной системе,а также явная передача сообщений, которую видит программист. По мнению Зейтца [1985]:
- Предпосылкой эксперимента Cosmic Cube было то, что межузловая связь должна хорошо масштабироваться для очень большого количества узлов. Прямая сеть , такая как гиперкуб, удовлетворяет этому требованию как с точки зрения совокупной пропускной способности, достигаемой по множеству одновременных каналов связи, так и с точки зрения осуществимости реализации. Гиперкуб . на самом деле представляет собой распределенный вариант сети непрямой логарифмической коммутации, такой как сети Omega или Banyan : того типа, который может использоваться в организациях с общим хранилищем Однако в гиперкубе пути связи проходят через разное количество каналов и поэтому имеют разные задержки. Таким образом, можно воспользоваться преимуществами локальности связи при размещении процессов в узлах.
J-Машина
[ редактировать ]J -Machine был разработан Биллом Далли и др. в Массачусетском технологическом институте предоставляют архитектурную поддержку, подходящую для актеров.Это включало следующее:
- Асинхронный обмен сообщениями
- Единое пространство адресов Актеров, на которые сообщения могут отправляться одновременно независимо от того, был ли Актер-получатель локальным или нелокальным.
- Форма конвейерной обработки актеров (см. модель актера ).
Параллельный Smalltalk (который можно моделировать с помощью Actors ) был разработан для программирования J Machine.
Язык программирования прототипов актеров
[ редактировать ]Хьюитт [2006] представил прототип языка программирования Актеров в том смысле, что он напрямую выражает важные аспекты поведения Актеров.Сообщения выражаются в формате XML с использованием обозначения :<tag>[<element>1 ... <element>] for
- “<”<tag>“>” <element>1 ... <element>n “<”/<tag>“>”
Семантика языка программирования определяется путем определения каждой программной конструкции как актера со своим собственным поведением. Выполнение моделируется путем передачи сообщений Eval между конструкциями программы во время выполнения.
Субъекты окружающей среды
[ редактировать ]Каждый Eval сообщение имеет адрес Актера, который выступает в качестве среды с привязками идентификаторов программы. Актеры среды неизменяемы, т. е. они не изменяются.Когда Request[Bind[identifier value] customer] принимается средой актера, создается новый актер среды, такой, чтокогда новый актер среды получает Request[Lookup[identifier’] customer’] тогда если identifier то же самое, что identifier’ отправлять customer’ Returned[value], иначе отправь EnvironmentRequest[Lookup[identifier’] customer’].Вышеупомянутое основано на Актере EmptyEnvironment которыйкогда он получит Request[Lookup[identifier] customer], отправляет customer Thrown[NotFound[identifier]].Когда он получает Bind запрос EmptyEnvironment действует как Environment выше.
Выражения
[ редактировать ]Язык программирования-прототипа содержит выражения следующих видов:
- <идентификатор>
- Когда Request[Eval[environment] customer] получено, отправьте environment Request[Lookup[<identifier>] customer]
- отправить <получатель> <сообщение>
- Когда Request[Eval[environment] customer] получено, отправьте <recipient> Request[Eval[environment] evalCustomer1] где evalCustomer1 новый актер такой, что
- когда evalCustomer1 получает сообщение Returned[theRecipient], затем отправь <communication>
- Request[Eval[environment] evalCustomer2] где evalCustomer2 новый актер такой, что
- когда evalCustomer2 получает сообщение Returned[theCommunication], затем отправь theRecipient theCommunication.
- <получатель>.<сообщение>
- Когда Request[Eval[environment] customer] получено, отправьте <recipient> Request[Eval[environment] evalCustomer1] такой, что
- когда evalCustomer1 получает сообщение Returned[theRecipient], затем отправь <message> Request[Eval[environment] evalCustomer2] такой, что
- когда evalCustomer2 получает сообщение Returned[theMessage], затем отправь theRecipient
- Request[theMessage customer]
- получатель ... <шаблон> i <выражение> я ...
- Когда Request[Eval[environment] customer] получено, отправьте customer новый актер theReceiver такой, что
- когда theReceiver получает сообщение com, затем создайте новый bindingCustomer и отправить среду
- Request[Bind[<pattern>i com] bindingCustomer] и
- если bindingCustomer получает Returned[environment’], отправлять <expression>i
- Request[Eval[environment’]]
- в противном случае, если bindingCustomer получает Thrown[...], пытаться <pattern>i+1
- поведение ... <шаблон> i <выражение> я ...
- Когда Request[Eval[environment] customer] получено, отправьте клиенту нового актера theReceiver такой, что
- когда theReceiver получает Request[message customer’], затем создайте новый bindingCustomer и отправить environment
- Request[bind[<pattern>i message] customer’] и
- если bindingCustomer получает Returned[environment’], отправлять <expression>i
- Request[Eval[environment’] customer’]
- в противном случае, если bindingCustomer получает Thrown[...], пытаться <pattern>i+1
- если bindingCustomer получает Returned[environment’], отправлять <expression>i
- {<выражение> 1 , <выражение> 2 }
- Когда Request[Eval[environment] customer] получено, отправьте <expression>1 Request[Eval[environment]] и одновременно отправить <expression>2 Request[Eval[environment]] customer].
- let <идентификатор> = значение <выражение> в <выражение> теле
- Когда message[Eval[environment] customer] получен, затем создайте новый evalCustomer и отправить <expression>value
- Request[Eval[environment] evalCustomer1.
- Когда evalCustomer получает Returned[theValue], создайте новый bindingCustomer и отправить environment
- Request[bind[<identifier> theValue] bindingCustomer]
- Когда bindingCustomer получает Returned[environment’], отправлять <expression>body Request[Eval[environment’] customer]
- сериализатор <выражение>
- Когда Request[Eval[environment] customer] получено, затем отправьте customer Returned[theSerializer] где theSerializer является новым действующим лицом, таким образом, что сообщения, направляемые theSerializer обрабатываются в порядке FIFO с помощью актера поведения, который изначально <expression>.Eval[environment] и
- Когда общение com получен theSerializer, затем отправьте поведение Actor Request[com customer’] где customer’ новый актер такой, что
- когда customer’ получает Returned[theNextBehavior] затем theNextBehavior используется в качестве актера поведения для следующего сообщения, полученного theSerializer.
Пример программы
[ редактировать ]Пример программы для простой ячейки памяти, которая может содержать любой адрес субъекта, выглядит следующим образом:
- Ячейка ≡
- получатель
- Запрос[Создать[первоначального] клиента]
- отправить клиенту возвращенный [ сериализатор ReadWrite(начальный)]
- Запрос[Создать[первоначального] клиента]
- получатель
Вышеупомянутая программа, создающая ячейку памяти, использует поведение ReadWrite, которое определяется следующим образом:
- ЧтениеЗапись(содержание) ≡
- поведение
- Запрос[читать[] клиент]
- { отправить клиенту возвращенное[содержание], ReadWrite(содержание)}
- Запрос[написать[x] клиент]
- { отправить возвращенного клиента[], ReadWrite(x)}
- Запрос[читать[] клиент]
- поведение
Вышеупомянутое поведение является конвейерным, то есть поведение может по-прежнему обрабатывать предыдущее сообщение чтения или записи, одновременно обрабатывая последующее сообщение чтения или записи.Например, следующее выражение создает ячейку x с начальным содержимым 5, а затем одновременно записывает в нее значения 7 и 9.
- пусть x = Cell.Create[5] в {x.write[7], x.write[9], x.read[]}
Значение приведенного выше выражения равно 5, 7 или 9.
См. также
[ редактировать ]Ссылки
[ редактировать ]- Генри Бейкер и Карл Хьюитт. Инкрементная сборка мусора процессов. Материалы симпозиума по языкам программирования искусственного интеллекта. Уведомления SIGPLAN от 12 августа 1977 г.
- Питер Бишоп. Модульно расширяемые компьютерные системы с очень большим адресным пространством. Докторская диссертация MIT EECS. Июнь 1977 года.
- Генри Бейкер. Акторные системы для вычислений в реальном времени. Докторская диссертация MIT EECS. Январь 1978 года.
- Карл Хьюитт и Расс Аткинсон. Спецификация и методы доказательства для сериализаторов Журнал IEEE по разработке программного обеспечения. Январь 1979 года.
- Кен Кан. Вычислительная теория анимации Докторская диссертация MIT EECS. Август 1979 года.
- Карл Хьюитт, Беппе Аттарди и Генри Либерман. Делегирование по передаче сообщений. Материалы Первой международной конференции по распределенным системам. Хантсвилл, Алабама. Октябрь 1979 года.
- Билл Корнфельд и Карл Хьюитт. Метафора научного сообщества Транзакции IEEE по системам, человеку и кибернетике. Январь 1981 года.
- Генри Либерман. Думать о множестве вещей одновременно, не запутываясь: параллелизм в акте 1, записка MIT AI 626. Май 1981 г.
- Генри Либерман. Предварительный обзор Акта 1, меморандум AI MIT 625. Июнь 1981 г.
- Билл Корнфельд. Параллелизм в решении задач Докторская диссертация MIT EECS. Август 1981 года.
- Даниэль Терио. Букварь по языку Act-1, записка MIT AI 672. Апрель 1982 г.
- Генри Либерман и Карл Хьюитт. Сборщик мусора в реальном времени, основанный на времени жизни объектов CACM, июнь 1983 г.
- Даниэль Терио. Проблемы разработки и реализации Акта 2. Технический отчет MIT AI 728. Июнь 1983 г.
- Генри Либерман. Объектно-ориентированный симулятор для пасечной конференции Американской ассоциации искусственного интеллекта, Вашингтон, округ Колумбия, август 1983 г.
- Карл Хьюитт и Генри Либерман. Проблемы проектирования в параллельной архитектуре для искусственного интеллекта, записка MIT AI 750. Ноябрь 1983 г.
- Чарльз Зейтц. Космический куб CACM. Январь 1985 года.
- Карл Мэннинг. Путешественник: обсерватория актеров ECOOP 1987. Также появляется в конспектах лекций по информатике, том. 276.
- Карл Мэннинг. Acore: Проектирование основного языка актеров и его компиляция магистерской диссертации. MIT EECS. Май 1987 года.
- Уильям Атас и Чарльз Зейтц Мультикомпьютеры: параллельные компьютеры для передачи сообщений IEEE Computer, август 1988 г.
- Уильям Атас и Нанетт Боден Кантор: Система актерского программирования для научных вычислений в материалах семинара NSF по объектно-ориентированному параллельному программированию. 1988. Специальный выпуск уведомлений SIGPLAN.
- Жан-Пьер Брио. От объектов к актерам: Исследование ограниченного симбиоза в Smalltalk-80 Rapport de Recherche 88-58, RXF-LITP, Париж, Франция, сентябрь 1988 г.
- Уильям Далли и Уиллс, Д. Универсальные механизмы параллелизма PARLE '89.
- В. Хорват, А. Чиен и В. Далли. Опыт работы с CST: программирование и внедрение PLDI. 1989.
- Акинори Ёнезава , ред. ABCL: объектно-ориентированная параллельная система MIT Press. 1990.
- Карл Хьюитт и Гуль Ага. Языки предложений защищенного Хорна: являются ли они дедуктивными и логическими? в области искусственного интеллекта в Массачусетском технологическом институте, Vol. 2. Массачусетский технологический институт Пресс, 1991.
- Карл Хьюитт и Джефф Инман. DAI между и между: от «интеллектуальных агентов» к открытым системным наукам. Транзакции IEEE о системах, человеке и кибернетике. Ноябрь/декабрь. 1991.
- Уильям Далли и др. Процессор, управляемый сообщениями: многокомпьютерный узел обработки с эффективными механизмами IEEE Micro. Апрель 1992 года.
- Дон Бокс, Дэвид Энебуске, Гопал Какаявая, Эндрю Лэйман, Ной Мендельсон, Хенрик Нильсен, Сатиш Татте, Дэйв Винер. Простой протокол доступа к объектам (SOAP) 1.1 Примечание W3C. Май 2000 года.
- Эдвард А. Ли и Стивен Нойендорфер (июнь 2004 г.). «Классы и подклассы в акторно-ориентированном проектировании» (кандидатская диссертация - расширенный автореферат). Конференция по формальным методам и моделям кодирования (MEMOCODE).
- Карл Хьюитт. Повторяющийся упадок логического программирования и почему оно будет перевоплощено Что пошло не так и почему: уроки исследований и приложений ИИ. Технический отчет SS-06-08. АААИ Пресс. Март 2006 года.