Здравствуйте, AndrewVK, Вы писали:
R>>У агента есть состояние
AVK>А есть ли?
Ну, если отталкиваться от различных определений агентов (в том числе и из Wikipedia), то агент с состоянием -- это более обыденная вещь, чем агент без состояния. Поскольку основная задача агента -- это реактивное и более-менее автономное поведение в достижении своей цели. Обеспечить автономность и реактивность без собственного состояния как-то затруднительно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[82]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, remark, Вы писали:
R>>Тут уже тема несколько десятков раз сменилась.
AVK>Ну вот такой я, всегда стремлюсь тему не сменять. Так оно понятнее и не приводит к бесконечным и бесполезным флеймам обо всем.
Ну это если ты с изначальной темой пришёл в разговор на изначальную тему. А если ты с изначальной темой пришёл в уже совсем другой разговор, то понятнее от этого отнюдь не стало.
R>>Какие навороты там не нужны?
AVK>Хитрые модели вроде TPL.
Никто и не говорит, что они там нужны.
R>>А никто и не говорит про что-то хитрое. И такие задачи тоже очень хорошо ложатся на агентную модель.
AVK>Они хорошо ложаться на любую модель. Поэтому чем она проще, тем лучше. Модель AsyncOperation всего с 2 значимыми методами намного проще агентов.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, remark, Вы писали:
R>>Я не уверен, имеет ли смысл говорить о том, что эти 2 модели одно и тоже, это больше философско-риторический вопрос. Я имел в виду, что эти 2 модели получаются одна из другой фактически "переименованием" понятий
AVK>Вот я и говорю, презерватив на глобус.
Ну хорошо, если это "презерватив на глобус" и типа теперь под это всё подпадает, то тогда приведи ещё пару моделей, которые получаются из тасков и датафлоу путём переименования понятий один-к-одному с чёткой аналогией между этими парами понятий.
Полагаю, если вещи таковы как ты говоришь, то это не должно составить проблемы.
AVK>>>А мы можем и не говорить, если этого не нужно. Я именно об этом тут и писал. Вот, к примеру, параллелю я рейтрейсер. Зависимостей нет вообще никаких. Пользуюсь при этом TPL. Что, в этом случае уже не task parallelism? Или он при этом какой то неполноценный?
R>>Ну это смешно.
AVK>Именно.
Ну а по-существу?
Из ты можешь получить из N полностью независимых сущностей систему, ты можешь получить только N отдельных систем. Ты когда запускаешь таски, ты потом не ждёшь из завершения? Код, который отображает потом картинку пользователю, не зависит от данных, подготовленных тасками рей-трейсинга?
Чёткий датафлоу граф вырисовывается. Параллельный рэй-трейсинг не начинается пока модель не считали из файла, а отрисовка не начинается пока не закончили рендеринг. Один кружочек расходится на N, а потом они сходятся опять в один.
Где ж тут "зависимостей нет никаких"???
Здравствуйте, remark, Вы писали:
R>Ну хорошо, если это "презерватив на глобус" и типа теперь под это всё подпадает, то тогда приведи ещё пару моделей, которые получаются из тасков и датафлоу путём переименования понятий один-к-одному
Путем переименования понятий можно сделать что угодно и этой казуистикой заниматься лично у меня нет никакого интереса.
R>Ну а по-существу?
А по существу не получится. Заниматься же разбором очередных переименований, натягиваний и аналогий мне не интересно, уж извини.
R>Чёткий датафлоу граф вырисовывается.
Угу. Получается, любая программа, которая обрабатывает данные в несколько этапов с зависимостью между этапами — это датафлоу. О чем я и говорил. Ну ОК, обозвал ты это все датафлоу, не хочу даже спорить о терминах. Дальше то что? Сколько воду в ступе не меси, все одно вода получится.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, eao197, Вы писали:
E>>>Это не единственный источник.
AVK>>И?
E>И твое замечание о том, что SObjectizer является источником моей приверженности FIFO, не соответсвует действительности.
В смысле, его проектировал не ты? Или тебя заставляли принимать некоторые решения по дизайну принудительно, без учета твоего мнения?
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
E>>И твое замечание о том, что SObjectizer является источником моей приверженности FIFO, не соответсвует действительности.
AVK>В смысле, его проектировал не ты? Или тебя заставляли принимать некоторые решения по дизайну принудительно, без учета твоего мнения?
В том смысле, что нельзя объять необъятного. SObjectizer -- это инструмент, построенный на некоем наборе принципов и архитектурных решений, выработанных лет двенадцать назад людьми гораздо более умными, чем я. А добавить в него что-то принципиально новое сейчас препятствует как недостаток ресурсов, так и требования к сохранению совместимости. Так что SObjectizer отражает далеко не все мои идеи и пристрастия.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[82]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
AVK>А если не заниматься перетасовкой терминов?
У агента нет общепризнаного одного определения. Но существующие в различных предметных областях определения указывают, что это сущность с собственным состоянием.
В MS-совской библиотеке асинхронных агентов из состава VS2010 агент -- это объект. Объект имеет соостояние.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[83]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
G>> Кстати, это вроде как уже не совсем actors model. Это довольно интересное обобщение.
AVK>Ну, remark в соседнем топике утверждал, что фьючерсы сотоварищи совсем уже не actors model, это совершенно отдельный task parallelism. Но это все спор о терминах.
Ну мало-ли что утверждал remark. Эти товарищи пойдут на что угодно, лишь бы выиграть спор. В то время как достаточно открыть википедию, и увидеть удивительное рядом, в виде характерных отсылок к actors model. Вдруг оказывается, что Делеи с Фьючерами у нас отлично определяются своей денотационной семантикой в рамках модели актеров.
Futures and delays are well defined in terms of their denotational semantics in the Actor model. These definitions do not require recourse to low level implementation concepts such as threads.
Впрочем, любому нормальному человеку понятно и без всякой теории, что изобразить фьючер на актерах — раз плюнуть, это по своей сути специальный частный случай обмена асинхронными сообщениями. Вот он, весь фьючер. Простейшая реализация на Эрланге, без запоминания (Фьючер "грязный") — просто заворачивающая в замыкание весьма частоупотребимый паттерн кода.
future( Actor, Message ) ->
Actor ! { self(), Message }, % послали сообщение актору, приложив свой ID процесса, чтобы актор имел возможность вернуть результат
fun() -> % конструируем безымянную функцию без аргументов для отложенного вычисления
receive { Actor, Response } -> Response end % в котором мы тупо получим ответ.
end.
% И все. Было бы о чем говорить. Проектируя в терминах actor model фьючер не является чем-то чужеродным - это один из типовых "паттернов проектирования"
Вот теперь смотрим — если я вместо явных посылок сообщений, всего лишь завернув их в функции, и напишу вот так:
Res = future( SomeObject, DoSomething ),
...
X = A + Res().
Я что, резко перестал actor model использовать? Что, так уже низя, да, потому что фьючеры — "это совсем не actors model"? По моему, глупостей уже на данную ветку достаточно с избытком. Совершенно очевидно, что это дружественные, дополняющие друг друга техники. Просто явная посылка сообщений нужна для потокового обмена, а стиль с промисами-фьючерами — нужен для синхронного взаимодействия в стиле RPC. Вот и все. А по сути это совершенно одно и то же.
Здравствуйте, AndrewVK, Вы писали:
G>> Кстати, это вроде как уже не совсем actors model. Это довольно интересное обобщение.
AVK>Ну, remark в соседнем топике утверждал, что фьючерсы сотоварищи совсем уже не actors model, это совершенно отдельный task parallelism. Но это все спор о терминах.
Простейший жизненный пример, показывающий, как великолепно фьючера дополняют сообщения и модель актеров, и что это суть одно и то же. Один из паттернов, который реально применялся у нас при разработке системы симуляции на Эрланге, и который можно повторить в любом языке.
Допустим, у нас есть дерево из "актеров". Некто шлет верхушке дерева rpc-style запрос, ответ на который он предполагает получить через фьючерс. Однако, верхушка дерева решает форварднуть запрос одному из своих потомков (выполняя его диспетчеризацию), потому, что он сам знает, как обработать запрос, но знает, кто сможет это сделать, выступая, таким образом, в роли брокера. Эта процедура, повторяясь рекурсивно, приводит к тому, что нужный actor в конце концов получает запрос, выполняет его, и кладет результат напрямую в фьючерс, который все это время путешествовал вместе с запросом.
Данный пример демонстрирует трактовку фьючерса в рамках модели актеров — как мэйлбокса для приема результата, а самого rpc вызова — как асинхронной посылки сообщения. От такой трактовки, как видите, есть польза. Вторая польза состоит в полной сетевой прозрачности — фьючерс, реализованный на сообщениях, легко сделать как межпроцессным так и межмашинным. Правда, это здорово, когда неважно, какой узел кластера выполняет ваш запрос, и где находится получатель результата? От то-то же.
