Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 38
Заинтересовавшись когда-то подобной темой, с удовольствием прочитал книгу «Шаблоны интеграции корпоративных приложений» Грегори Хопа, описывающую в подробностях системы обмена сообщениями.
Акторы можно классифицировать по многим признакам, но самым важным является допустимое количество входов. У акторов — идейных наследников сетей Петри (workflow, dataflow) количество входов не ограничено. У акторов Хьюита (Akka) входа ровно два — для входящих сообщений и для внутреннего состояния.
Почему-то авторы, пишущие об акторах, как правило, знакомы только с моделью Хьюита. Отсюда утверждения типa «акторы не защищены от перегрузки». Акторы Хьюита — да, не защищены, потому что нельзя увеличить число входов. Dataflow актор защитить от перегрузки легко — стоит лишь добавить обратную связь по переполнению и завести ее на добавочный вход.
Почему-то авторы, пишущие об акторах, как правило, знакомы только с моделью Хьюита. Отсюда утверждения типa «акторы не защищены от перегрузки». Акторы Хьюита — да, не защищены, потому что нельзя увеличить число входов. Dataflow актор защитить от перегрузки легко — стоит лишь добавить обратную связь по переполнению и завести ее на добавочный вход.
Мне казалось, что «модель акторов» (она же Actor Model на английском) — это именно то, что было озвучено сперва Хьюитом, а потом подхвачено Клингером и Агха. Об этой модели акторов и идет речь.
Где можно прочитать про «модель акторов» с другими корнями?
Где можно прочитать про «модель акторов» с другими корнями?
1. A STRUCTURED DESCRIPTION OF DATAFLOW ACTORS AND ITS APPLICATION. Johan Eker J¨orn W. Janneck
2. Robust Workflows for Science and Engineering. David Abramson, Blair Bethwaite, Colin Enticott, Slavisa Garic, Tom Peachey Anushka Michailova, Saleh Amirriazi, Ramya Chitters
Собственно проблема в том, что при описании dataflow и workflow сетей (а по большому счету, это одно и то же) узлы этих сетей обычно называют не акторами, а как-нибудь по другому, хотя они именно акторы и есть.
Так что читайте все подряд по dataflow и workflow.
2. Robust Workflows for Science and Engineering. David Abramson, Blair Bethwaite, Colin Enticott, Slavisa Garic, Tom Peachey Anushka Michailova, Saleh Amirriazi, Ramya Chitters
Собственно проблема в том, что при описании dataflow и workflow сетей (а по большому счету, это одно и то же) узлы этих сетей обычно называют не акторами, а как-нибудь по другому, хотя они именно акторы и есть.
Так что читайте все подряд по dataflow и workflow.
Собственно проблема в том, что при описании dataflow и workflow сетей (а по большому счету, это одно и то же) узлы этих сетей обычно называют не акторами, а как-нибудь по другому
Ну да. Там будет про dataflow/workflow. Но не про «традиционную» модель акторов от Хьюита.
хотя они именно акторы и есть
Или это вам лично так кажется.
Чтобы было понятно: есть уже давно ставшим общеупотребительным термин «модель акторов», под которым более-менее понятно, что понимается. Вы, как приверженец dataflow-модели, можете считать, что модель акторов есть частный случай dataflow-модели. Однако вряд ли ваш взгляд на вещи найдет широкое понимание. У меня, например, не находит.
Вероятно, вы и арифметические операции с 2 параметрами не рассматриваете как частный случай математических функций со многими параметрами?
Сильно зависит от контекста. Если для обучения арифметическим операциям детей в начальных классах школы — то, конечно же, не рассматриваю. При этом вы уходите на доказательства по аналогии, что суть демагогия.
Проблема в том, что вы выдвинули тезис о том, что actor model — это частный случай dataflow. При том, что термин actor model уже является устоявшимся термином. И нужно что-то более существенное, нежели аналогия с арифметическими операциями, для обоснования вашего термина.
Видите ли, вы ссылаетесь на работу от 2003-го года, в которой авторы сами пишут:
Они английским по белому говорят «которые мы называем _акторами_, но которые могут быть названы процессами в других моделях». Т.е. авторы одной работы, вышедшей через 30 лет после работы Хьюита используют термин _актор_ в контексте dataflow-а. При том, что они пытаются ввести такое понятие, как dataflows actors. Не просто actors, а именно dataflow actors.
Больше напоминает, что вы прочли про dataflows actors, вам показалось, что это обобщение, в том числе, и Хьюитовских акторов, и теперь вы носитесь с этой идеей. Ничего не имею против ваших личных взглядов на проблемы dataflows actors.
Однако, в статье речь идет про Хьюитовских акторов и их проблемы, в том числе и проблемы отсутствия защиты от перегрузки. А вовсе не о так любимых вами dataflow actors.
Проблема в том, что вы выдвинули тезис о том, что actor model — это частный случай dataflow. При том, что термин actor model уже является устоявшимся термином. И нужно что-то более существенное, нежели аналогия с арифметическими операциями, для обоснования вашего термина.
Видите ли, вы ссылаетесь на работу от 2003-го года, в которой авторы сами пишут:
In all dataflow models of computation, the model components (which we call actors,
and which might also be called processes in other models of computation) communicate
by sending each other packets of data called tokens along unidirectional channels with
exactly one reader and one writer.
Они английским по белому говорят «которые мы называем _акторами_, но которые могут быть названы процессами в других моделях». Т.е. авторы одной работы, вышедшей через 30 лет после работы Хьюита используют термин _актор_ в контексте dataflow-а. При том, что они пытаются ввести такое понятие, как dataflows actors. Не просто actors, а именно dataflow actors.
Больше напоминает, что вы прочли про dataflows actors, вам показалось, что это обобщение, в том числе, и Хьюитовских акторов, и теперь вы носитесь с этой идеей. Ничего не имею против ваших личных взглядов на проблемы dataflows actors.
Однако, в статье речь идет про Хьюитовских акторов и их проблемы, в том числе и проблемы отсутствия защиты от перегрузки. А вовсе не о так любимых вами dataflow actors.
аналогия не всегда демагогия. В данном случае аналогия самая прямая. Акторы — это асинхронные функции. То есть, функции, исполняющиеся, когда есть все необходимое для их исполнения — входные данные и вычислительные ресурсы. И выделять акторы с 2 входами в отдельную категорию так же наивно, как выделять сложение и умножение из всего множества математических функций только на том основании, что у них 2 аргумента. Да, это может иметь педагогический смысл, но вы же не хотите оставаться на уровне начальной школы?
И выделять акторы с 2 входами в отдельную категорию так же наивно, как выделять сложение и умножение из всего множества математических функций только на том основании, что у них 2 аргумента.
Может проблема в том, что вы говорите про математические функции, а я про практику использования акторов? На практике у акторов нет двух входов.
Сюрприз, правда?
Вам хочется думать, что с точки зрения математики, второй вход для актора — это его состояние. На практике, однако, состояние актора не является для него входом. Особенно если мы находимся в рамках императивных ОО-языков.
Вот и получается, что с точки зрения теории и досужих рассуждений с доказательствами по аналогии — у вас одно. А на практике у меня, скажем, несколько другое. И какой-то дополнительный «вход» для обратной связи привязывать-то и некуда.
С таким же успехом вы могли бы утверждать, что рекурсивных функций на практике не существует, поскольку вы программируете на Фортране IV.
Опять доказательство по аналогии.
Давайте еще раз: статья о том, что происходит на практике при использовании акторов Хьюита. На практике акторы не защищены от перегрузок. И с этим нужно жить.
Тем, кому приходится с этим жить, как-то все равно, есть ли теоритические работы, описывающие общие случаи акторов с N входами и M выходами, или таковых нет. А если они и есть, то как там обстоят дела с защитой от перегрузки (пока что советы теоритиков вызывают смех в зале).
Попробуйте дать обычному разработку на Akka формулы из статьи «A STRUCTURED DESCRIPTION OF DATAFLOW ACTORS AND ITS APPLICATION», на которую вы ссылаетесь. И посмотрите, как это поможет при разработке реальной программной системы.
Давайте еще раз: статья о том, что происходит на практике при использовании акторов Хьюита. На практике акторы не защищены от перегрузок. И с этим нужно жить.
Тем, кому приходится с этим жить, как-то все равно, есть ли теоритические работы, описывающие общие случаи акторов с N входами и M выходами, или таковых нет. А если они и есть, то как там обстоят дела с защитой от перегрузки (пока что советы теоритиков вызывают смех в зале).
Попробуйте дать обычному разработку на Akka формулы из статьи «A STRUCTURED DESCRIPTION OF DATAFLOW ACTORS AND ITS APPLICATION», на которую вы ссылаетесь. И посмотрите, как это поможет при разработке реальной программной системы.
Есть и практические реализации акторов с N входами, например, TPL dataflow, Intel Threading Building Blocks.
А в Akka вроде уже добавили защиту от перегрузок, во всяком случае, понятие back-pressure упомянуто в http://doc.akka.io/docs/akka/2.5.3/scala/stream/stream-flows-and-basics.html
А в Akka вроде уже добавили защиту от перегрузок, во всяком случае, понятие back-pressure упомянуто в http://doc.akka.io/docs/akka/2.5.3/scala/stream/stream-flows-and-basics.html
Вот только в Intel TBB понятие актора не используется, насколько я помню.
Так что исходный тезис о том, можно ли отождествлять dataflow и actor model, все еще нуждается в доказательстве.
Если вы посмотрите на back-pressure из Akka, то увидите, что этот back-pressure сделан не для акторов, а для Akka Streams, дополнительной штуке, которая существует сбоку от акторов.
Так что исходный тезис о том, можно ли отождествлять dataflow и actor model, все еще нуждается в доказательстве.
Если вы посмотрите на back-pressure из Akka, то увидите, что этот back-pressure сделан не для акторов, а для Akka Streams, дополнительной штуке, которая существует сбоку от акторов.
«Проблема в том, что вы выдвинули тезис о том, что actor model — это частный случай dataflow».
Не вижу здесь никакой проблемы. Узлы dataflow сети названы акторами уже в 1975 году, в одной из первых работ по dataflow: Jack B. Dennis, “First Version of a Data Flow Procedure Language”. То, что actor model Хьюита — частный случай dataflow, ясно любому, кто пытался реализовать и то, и другое.
Не вижу здесь никакой проблемы. Узлы dataflow сети названы акторами уже в 1975 году, в одной из первых работ по dataflow: Jack B. Dennis, “First Version of a Data Flow Procedure Language”. То, что actor model Хьюита — частный случай dataflow, ясно любому, кто пытался реализовать и то, и другое.
ясно любому, кто пытался реализовать и то, и другое.
Где можно посмотреть на ваши реализации?
Спасибо, повеселили еще раз. Это что, тестовое задание для трудоустройства в LuxSoft?
первая ссылка — да, тестовое задание, но не в люксофт. Им требовалась именно квалификация в многопоточности. Решение их не устроило, сказали что некорректное. А теперь поделитесь, что именно вас развеселило.
После слов:
То, что actor model Хьюита — частный случай dataflow, ясно любому, кто пытался реализовать и то, и другое.хотелось увидеть что-то уровнем повыше студенческой курсовой.
И что, это вас развеселило? Не оправдавшиеся ожидания обычно огорчают.
Я же написал: «ясно любому, кто пытался реализовать и то, и другое». Пытался. Не обязательно довел до совершенства. Потому что идейная сущность (то, что actor Хьюита — частный случай dataflow), она становится ясной довольно быстро. После чего становится скучно. И это не бог весть какое открытие, именно на уровне студенческой курсовой. А вы что, вообразили, что у нас спор кандидатов на премию Тьюринга?
Я же написал: «ясно любому, кто пытался реализовать и то, и другое». Пытался. Не обязательно довел до совершенства. Потому что идейная сущность (то, что actor Хьюита — частный случай dataflow), она становится ясной довольно быстро. После чего становится скучно. И это не бог весть какое открытие, именно на уровне студенческой курсовой. А вы что, вообразили, что у нас спор кандидатов на премию Тьюринга?
Не оправдавшиеся ожидания обычно огорчают.Так я увидел как раз то, что ожидал.
Ну и повторю еще раз: вы, лично вы, можете видеть что угодно и где угодно. Считаете вы, что акторы Хьюита — это частный случай dataflow actors — никто вам этого не запретит. Статья не про это, а про то, что делать в случае акторов Хьюита.
Разводить демагогию на тему того, что одноколесный, двух-колесный и трех-колесный велосипеды — это все частные случаи для понятия «велосипеда», и еще более частные случаи понятия «транспортного средства», мне не интересно. Поскольку на практике разница между всеми этими типами велосипедов просто значительная.
Вот так же и с акторами, когда их пытаются применить в задачах посложнее студенческой курсовой.
Dataflow актор защитить от перегрузки легко — стоит лишь добавить обратную связь по переполнению и завести ее на добавочный вход.
Попутно вопрос: допустим, есть актор B, на которого сыпятся сообщения от акторов C, D, E и далее по списку. Общий темп отсылки сообщений актору B превышает способности B по обработке входящих сообщений. Этот самый «добавочный вход» кому нужно завести и куда?
от актора B на акторы C, D, E, а если найдется узел, питающий C, D, E, тогда на него.
Ну и зачем этот вход акторам C, D и E? Более того, откуда этот вход будет появляться во run-time, если, скажем, ссылку на B актор C получает в run-time, отправляет актору B одно-единственное сообщение и выбрасывает данную ссылку как ненужную?
этот вход акторам C, D и E нужен, чтобы вести себя прилично в обществе. И закладывать его надо при описании, а не в рантайме. Если же, как вы сказали, ссылку на B актор C получает в сообщении, то здесь есть разные варианты. Например, обязать посылающего, чтобы он зарезервировал у B место для приема сообщения от С. Или разбить актор С на 2 стадии — первая получает ссылку на B и делает запрос к B на резервирование места, посылая в запросе ссылку на вторую стадию. Когда у B освобождается место, он оповещает вторую стадию. В любом случае, у акторов необходимо размещать дополнительные управляющие входы, которые блокировали бы их работу до получения необходимого набора ресурсов.
Или разбить актор С на 2 стадии — первая получает ссылку на B и делает запрос к B на резервирование места, посылая в запросе ссылку на вторую стадию.
Спасибо, повеселили.
Вот этот «запрос к B на резервирование места» — он какой будет? Синхронный или асинхронный? Если асинхронный, то чем этот запрос отличается от простой и тупой прямой отсылки нужного сообщения? И кто гарантирует, что сам этот запрос не станет причиной перегрузки B?
Асинхронный, естественно. А отличается тем, что общее число таких запросов ограничено общим числом акторов. Отсюда и решение — пусть актор (точнее, один из его входов) сам выступает в качестве запроса, а очередь запросов сделать в виде списка, а не массива. Тогда постановка такого запроса не потребует дополнительной памяти и не сможет вызывать перегрузку.
А отличается тем, что общее число таких запросов ограничено общим числом акторов.
А общее число акторов мы знаем откуда?
Вы, походу, слишком долго варитесь в области dataflow-программирования. Это там специфика такая, что количество вычислительных сущностей (узлов, процессов) и их взаимосвязи известны заранее.
Отсюда и решение — пусть актор (точнее, один из его входов) сам выступает в качестве запроса, а очередь запросов сделать в виде списка, а не массива.
Либо вы предлагаете то, чего я не понимаю, либо ваша идея в том, чтобы самих акторов прописывать в интрузивный список. Что есть отстой. Ибо работать будет только для ограниченного типа сценариев (например, когда понятно, что запрос типа X к актору B любой другой актор не может отсылать более одного раза.
А общее число акторов нам знать и не нужно. Мы его нигде не используем.
Это в хардверном dataflow количество вычислительных сущностей известно заранее, в силу естественных причин. А в софтверном нам никто не запрещает генерить акторы динамически.
Не акторов, я уточнил — входов. Еще точнее — выходов. И запрос у нас не типа X, а запрос на резервирование места под запись. Такие запросы не нужно отсылать более одного раза — достаточно в запросе указать количество запрашиваемых мест.
Это в хардверном dataflow количество вычислительных сущностей известно заранее, в силу естественных причин. А в софтверном нам никто не запрещает генерить акторы динамически.
Не акторов, я уточнил — входов. Еще точнее — выходов. И запрос у нас не типа X, а запрос на резервирование места под запись. Такие запросы не нужно отсылать более одного раза — достаточно в запросе указать количество запрашиваемых мест.
Посмотрите http://www.reactivemanifesto.org и связанные имплементации. Там эта тема фигурирует под названием http://www.reactivemanifesto.org/glossary#Back-Pressure
«Связанные имплементации» — это какие именно? Уже упоминавшиеся выше Akka Streams?
Простите, правильнее было бы давать эту ссылку http://www.reactive-streams.org/announce-1.0.0
Ну так первая имплементация из перечисленных там — это Akka Streams и есть, поскольку сам Reactive Manifesto делался, в том числе, и людьми, стоящими за Akka. В том числе и для продвижения Akka.
Тем не менее, посмотрите на спецификацию этих самых reactive streams. Там subscriber должен вызвать Publisher.subscribe для того, чтобы получать сообщения от конкретного publisher-а.
Что для моего примера выше означает, что актор B должен сперва подписаться на паблишеров C, D, E и всех прочих. Это совсем не та ситуация, о которой я говорю.
Тем не менее, посмотрите на спецификацию этих самых reactive streams. Там subscriber должен вызвать Publisher.subscribe для того, чтобы получать сообщения от конкретного publisher-а.
Что для моего примера выше означает, что актор B должен сперва подписаться на паблишеров C, D, E и всех прочих. Это совсем не та ситуация, о которой я говорю.
Немного заблудился в комментариях. О какой ситуации говорите вы?
Вот об этой. Суть в том, что B не должен знать ни про C, ни про D, ни про E. Да и C, D и E могут узнать про B только на короткий момент времени, после чего забудут о нем.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Объединяем акторов и SEDA-подход: зачем и как?