Comments 20
Стоит отметить подход к обработке ошибок. Часто акторы не гарантируют доставку сообщений (аналогия с почной работает :-)), и при ошибках принято прото завершать актор.
Акторы в чем-то напоминают процессы ОС со своей виртуальной памятью. Процесс так же может завершиться при ошибке потеряв свое (возможно некорректное) состояние. Это сильно упрощает отладку — каждый актор можно тестировать независимо от остальной системы.
Польза ФП не в том, что удобно считать тайминги — эту функциональность можно встроить в любой язык. Основная польза — в изоляции состояний. Актор не должен изменять что-то в чужих данных, что хорошо согласуется с запретом на разрушающее присваивание.
Кстати, забавно, что хотя акторы не подходят под идеи создателя Пролога, первые реализации Erlang написаны именно на Прологе :-). В общем то на Прологе акторы сравнительно легко реализуются — похожая техника применяется например в Mozart/Oz.
Акторы в чем-то напоминают процессы ОС со своей виртуальной памятью. Процесс так же может завершиться при ошибке потеряв свое (возможно некорректное) состояние. Это сильно упрощает отладку — каждый актор можно тестировать независимо от остальной системы.
Польза ФП не в том, что удобно считать тайминги — эту функциональность можно встроить в любой язык. Основная польза — в изоляции состояний. Актор не должен изменять что-то в чужих данных, что хорошо согласуется с запретом на разрушающее присваивание.
Кстати, забавно, что хотя акторы не подходят под идеи создателя Пролога, первые реализации Erlang написаны именно на Прологе :-). В общем то на Прологе акторы сравнительно легко реализуются — похожая техника применяется например в Mozart/Oz.
Стоит отметить подход к обработке ошибок. Часто акторы не гарантируют доставку сообщений (аналогия с почной работает :-)), и при ошибках принято прото завершать актор.
Согласен, что это проверенный и работающий подход к обработке ошибок. Про него я узнал из Erlanga, но не знаю, был он там применен впервые или заимствован из другого языка. В этом плане первоисточник был бы интересен — может быть есть еще какие-нибудь хорошие идеи. Если кто может подсказать, пожалуйста, напишите.
При этом модель авторов не налагает никаких ограничений на обработку ошибок, Существуют другие приемы, которые показали себя на практике. О некоторых из них, я и хотел рассказать в следующих статьях.
Польза ФП не в том, что удобно считать тайминги — эту функциональность можно встроить в любой язык. Основная польза — в изоляции состояний. Актор не должен изменять что-то в чужих данных, что хорошо согласуется с запретом на разрушающее присваивание.
Согласен, что ФП имеют много разных преимуществ. Только не пойму, как в императивных языках встроить тайминги, чтобы не потерять тот же эффект? Первое, что приходит в голову, это встроить тайминг, например, в конце тела каждого составного оператора. Но как это скажется на производительности? Может быть есть такие реализации или исследования на эту тему?
Ходил как то на митап по языку Go, там говорили, что есть 2 вещи, куда имеет смысл воткнуть проверку для прерывания выполнения процесса: в вызовы функций (это они реализовали в версии 1.2) и в каждую итерацию for / while цикла (ещё не реализовали).
В Erlang оба этих случая сводятся к одному, т.к. реализовать цикл без вызова функции невозможно в принципе (только рекурсия).
В Erlang оба этих случая сводятся к одному, т.к. реализовать цикл без вызова функции невозможно в принципе (только рекурсия).
Спасибо за статью! Конечно пишите, тема очень интересная.
Вы случайно не сталкивались с акторными моделями применительно к Smalltalk? Как мне кажется, его модель сообщений очень аккуратно ложится в концепцию акторов. По моему, я даже где-то подобное видел, вроде диалекта Smalltalk с поддержкой акторов.
Вы случайно не сталкивались с акторными моделями применительно к Smalltalk? Как мне кажется, его модель сообщений очень аккуратно ложится в концепцию акторов. По моему, я даже где-то подобное видел, вроде диалекта Smalltalk с поддержкой акторов.
Нет, сам я не работал со Smalltalk. У Carl Hewitt есть статья, датированная 2012 годом, Actor Model of Computation: Scalable Robust Information Systems — это обзор сделанной работы и достижений. Так вот, буквально в первом абзаце он пишет: «Unlike previous models of computation, the Actor model was inspired by physical laws. It was also influenced by the programming languages Lisp, Simula 67 and Smalltalk-72, as well as ideas for Petri Nets, capability-based systems and packet switching.» Так что, судя по всему ранние версии Smalltalk выступили источником идей. Как я понимаю, был заимствован сам принцип обмена сообщениями.
Как ни странно, но в Википедии эти моменты отражены достаточно подробно: en.wikipedia.org/wiki/History_of_the_Actor_model#Smalltalk
Ссылок много (даже такие), но тот факт, что Кэй для считает первичной особенностью Smalltalk именно концепцию отправки сообщений, достаточно последовательно им же и озвучивается.
По поводу имплементации в Smalltalk -80 можно действительно найти много ссылок на работу Jean-Pierre Brio, и, как пример, реализация поместилась в нескольких слайдах тут
Ссылок много (даже такие), но тот факт, что Кэй для считает первичной особенностью Smalltalk именно концепцию отправки сообщений, достаточно последовательно им же и озвучивается.
По поводу имплементации в Smalltalk -80 можно действительно найти много ссылок на работу Jean-Pierre Brio, и, как пример, реализация поместилась в нескольких слайдах тут
Извините за оффтопик, но почему Actors переводят на русский как «акторы», а не «актёры»?
Скорее всего, Вот поэтому
Мне кажется это способ ограничения круга возможных сущностей под именем Актер до единственной — связанной с конкретной областью и контекстом — Актор. Легче узнается и воспринимается на слух.
в мире императивного программирования практически ничего неизвестно о функциональном – его как бы нет, по крайней мере, это было до недавнего времени, а в мире функционального программирования императивное подвергается критике. Может есть у кого мысли, почему так произошло?
Я вам не скажу за всю Одессу… Но у меня лично просто по-другому мозг устроен. Мне проще мыслить в категории «разделяй и влавствуй». «Сделал что-то с состоянием, получил новое состояние, сделал то же самое с новым состоянием… О, а вот же и терминальное условие = решение»
Тема на самом деле интересная. Если будете организовывать какие-либо конференции — пишите, приглашайте! Особенно интересует матчасть.
Стиль изложения у вас тоже неплохой. Можно чуть больше визуализации — схем\графиков(вместо списков). Аналогии в тексте проводите весьма ясно и понятно. Для графиков можете использовать yEd
Начиная с 30-ой минуты в видео вы рассказываете, как плохо отлаживать ПО в эрланге, что отладчика там нет… И слава богу :)
В ноде я как-то пытался отлаживать через node-inspector, поставил брекпоинт, нода остановилась, и, пока я смотрел на переменные в вотчлисте, истекла пара таймаутов. После того, как я нажал run, процесс выдал ошибки и пошел совсем по другому пути. С тех пор я просто вставляю принты и перезапускаю ноду.
В ноде вообще-то таймаутов почти нет, и всё равно они у меня сработали. В эрланге же их рекомендуют ставить на каждый receive. Поэтому проблем с паузой там будет на порядок больше. Особенно, если ставить на паузу всю эрланг-машину. И, конечно, такой метод не годится для отладки продакшн системы на лету.
Это, как я понимаю, общая проблема для актор-систем, если они написаны аккуратно, т.е. с таймаутами.
Поэтому, принты, принты и только принты. И вот с этим в эрланге всё очень хорошо: можно подключиться к ноде на лету (даже продакшн), на лету включить трейс на вызов любых функций, на лету получить и время, и переданные аргументы, и результат, и также на лету пропатчить. Такого мне очень сильно не хватает в других языках, включая ноду с её node-inspector.
В ноде я как-то пытался отлаживать через node-inspector, поставил брекпоинт, нода остановилась, и, пока я смотрел на переменные в вотчлисте, истекла пара таймаутов. После того, как я нажал run, процесс выдал ошибки и пошел совсем по другому пути. С тех пор я просто вставляю принты и перезапускаю ноду.
В ноде вообще-то таймаутов почти нет, и всё равно они у меня сработали. В эрланге же их рекомендуют ставить на каждый receive. Поэтому проблем с паузой там будет на порядок больше. Особенно, если ставить на паузу всю эрланг-машину. И, конечно, такой метод не годится для отладки продакшн системы на лету.
Это, как я понимаю, общая проблема для актор-систем, если они написаны аккуратно, т.е. с таймаутами.
Поэтому, принты, принты и только принты. И вот с этим в эрланге всё очень хорошо: можно подключиться к ноде на лету (даже продакшн), на лету включить трейс на вызов любых функций, на лету получить и время, и переданные аргументы, и результат, и также на лету пропатчить. Такого мне очень сильно не хватает в других языках, включая ноду с её node-inspector.
Начиная с 30-ой минуты в видео вы рассказываете, как плохо отлаживать ПО в эрланге, что отладчика там нет… И слава богу :)
Отладчик в Erlang есть. В этом месте говорится немного о другом: в общем случае, в акторных системах может отсутствовать причинно-следственная связь между текущим состоянием и предыдущим. Об этом же я написал в статье в абзаце под заголовком Ложка дегдя… А при отладке мы как раз пытаемся установить причину некоторого некорректного состояния. Это не значит, что отладка невозможна вообще, но, по крайней мере, она значительно затруднена.
Проблема с таймаутами, которые Вы описываете, существует и при отладке обычных многопоточных приложений.
И, конечно, такой метод не годится для отладки продакшн системы на лету.
Согласен, отладка не для продакшена.
Что касается отладки во время разработки, то, во-первых, таймауты можно сделать конфигурируемыми. Это позволит успеть выполнить все проверки прежде, чем хотя бы один из истечет. Во-вторых, можно писать юнит-тесты с использованием Mock-объектов и заглушек. Когда мы начинали осваивать акторы, первое впечатление которое у нас возникло — хрустальная система. Идея — все отлично, по отдельности каждый маленький компонент — все здорово, но как только начинаешь собирать что-то более-менее крупное — все сыпется, а причину найти, порой сложновато. Вообщем, считаю, что в нашем случае, тесты очень сильно помогли. Есть еще ряд идей, чем можно компенсировать сложности отладки — об этом я собираюсь написать в одной из следующих статей.
На мой взгляд, подсчет тайминга нужно реализовывать на уровне исполнения команд переходов ядром процессора. Команда перехода — очень хороший момент для проверки возможности переключения на другой поток.И, интересно, компилятор насколько точно может оценивать относительную продолжительность выполнения того или другого фрагмента кода? Можно принудительно вставлять команды передачи управления в каждой некритической секции, а в критических, исполнение которой по оценке превышает некоторый предел — выдавать предупреждение, но не только разработчику, но так же и оставлять некий вызов системы при запуске приложения, о том, что приложение содержит длительно выполняющиеся критические секции, чтобы пользователь знал, что это приложение может подмораживать переключение процессов и мог принять решение — использовать это приложение или нет.
UFO just landed and posted this here
Здравствуйте, merhalak. Так получилось, что только сейчас увидел Ваш комментарий. Спасибо за замечание. Исправление внесено вот в таком виде (все что ниже — это правка)
«что это всего лишь одна из возможных реализаций, которая не может реализовать всю акторную модель в „полном объеме“.
Действительно, в phd диссертации Foundations of Actor Semantics William Duglas Clinger (ученик Карла Хьюита) показывает, что акторная модель обладает неограниченным недетерминизмом, в то время как машина Тьюринга является ограниченно недетерминированной. Из этого он и Карл Хьюит делают вывод, что существуют алгоритмы, которые можно реализовать в акторной модели, но нельзя реализовать на машине Тьюринга. Поэтому любая попытка реализации акторной модели на „обычных“ компьютерах, реализующих вычислимость по Тьюрингу, приведет к тому, что будет реализован лишь частный случай акторной модели.»
«что это всего лишь одна из возможных реализаций, которая не может реализовать всю акторную модель в „полном объеме“.
Действительно, в phd диссертации Foundations of Actor Semantics William Duglas Clinger (ученик Карла Хьюита) показывает, что акторная модель обладает неограниченным недетерминизмом, в то время как машина Тьюринга является ограниченно недетерминированной. Из этого он и Карл Хьюит делают вывод, что существуют алгоритмы, которые можно реализовать в акторной модели, но нельзя реализовать на машине Тьюринга. Поэтому любая попытка реализации акторной модели на „обычных“ компьютерах, реализующих вычислимость по Тьюрингу, приведет к тому, что будет реализован лишь частный случай акторной модели.»
Sign up to leave a comment.
Модели акторов 40 лет