Здравствуйте, WolfHound, Вы писали:
WH>>>1)Актор просто по определению это связка потока исполнения и очереди сообщений. V>>Неверно. WH>Это прямо следует из определения по ссылке. WH>
WH>В компьютерных науках модель акторов представляет собой математическую модель параллельных вычислений, которая трактует понятие «актор» как универсальный примитив параллельного численного расчёта: в ответ на сообщения, которые он получает, актор может принимать локальные решения, создавать новых акторов, посылать свои сообщения, а также устанавливать, как следует реагировать на последующие сообщения.
Давай на пальцах,а то непонимайт, где же тут "прямо"?
Здравствуйте, WolfHound, Вы писали:
WH>Это подход с точки зрения модели системы является более устойчивым к всяким бякам. WH>В частности он не сваливается в O(N^2) на ровном месте.
Чтобы оно сваливалось в O(N^2), надо чтобы адрес каждый раз получался минимум за O(N) и сообщение доставлялось (т.е. ресолвился адрес) тоже за O(N), где N — кол-во акторов... а так-то обе операции выполнимы за O(1).
Цимус в том, что нет никакого смысла посылать сообщение конкретному каналу в общем случае. Даже если в Сингулярити это на уровне языка видится именно так, реально это может происходить не так. Асинхронная отсылка может идти в общую очередь с привязанным идентификатором канала, а эта очередь затем может разгребаться на пуле потоков. Почему так? Предлагаю порассуждать на предмет как времени жизни каналов, так и на предмет того, что канал вовсе не обязан иметь выделенный физический поток-обработчик сообщений. Асинхронная модель поверх событийной (то бишь на пуле потоков) хороша тем, что не требует обязательного физического потока на каждый актор. Хотя, никто не запрещает акторам создавать такие потоки для своих внутренних нужд. Просто я не представляю работу на каналах обработчиков хотя бы для тысячи подключений, если к каждому подключению привязывается минимум 5 акторов для логики всего приложения...
(Хотя в некоторых случаях, например для случая обработки медиа, для каждой конференции создавался поток-миксер, поэтому медиа шло в конкретный канал. Но там оно шло от многих к одному, т.е. кол-во потоков равно кол-ву конференций и заведомо на прядок примерно меньше общего кол-ва участников. Ну и все вещи вокруг времени жизни и прочих тонкостей решались ручками. В случае общих очередей оно решается автоматом, что удобнее.)
И на последок как пример — асинхронный ввод/вывод в виндах в сокеты. Сообщения отсылаются в одну "точку входа" с идентификатором сокета. Очередь на каждый физический интерфейс унутре одна (она доступна какому-нить драйверу протокола сверху интерфейса), это точно, и разгребается она через алгоритмы QoS или кастомные драйверы с той же целью. Ничего быстрее в природе на сегодня не существует. Ес-но никаких O(N^2) нет, это выдумки или примеры неудачных решений в лоб, типа пузырьковых сортировок. Любой адрес можно спроектировать так, чтобы ресолвинг по нему шел за O(1).
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, sergeyt4, Вы писали:
V>А как ты это делаешь в более простом DI-контейнере? А исопльзуешь ли вообще подход DI? Например, используешь ли ты обычные события дотнета вне WinForms (или другого GUI)? А как ты в WinForms узнаешь, кто подпишется на твоё событие? ИМХО, подпишется кто угодно...
В WinForms все просто — все события от контролов обрабатываются в самой форме. т.е. она — единственный подписчик своих контролов. Вне форм события мы не используем. Именно потому что неизвестно, кто на них подпишется, и глядя на метод никогда не догадаешься, что он, оказывается, является обработчиком события от определенного класса. Мы используем вместо этого callback-интерфейс с одним методом. По нему легко отыскать подписчиков. (По сути event — это и есть интерфейс с одним методом, но анонимный.)
Используем ли мы подход DI? трудно сказать. Возможно и используем, не зная, что теперь это так называется.
Но идеология приложения, раздробленного на миллион независимых запчастей, которые чудесным образом собираются в одно при запуске, меня не устраивает. В нем крайне сложно разобраться — кто с кем и зачем взаимодействует, чтобы потом добавлять новый функционал или менять старый. Видимо, нужна очень подробная документация. (Но кто ее поддерживать в актуальном состоянии-то будет?) Наши приложения конечно не монолитны, но и не состоят из большого числа мелких "атомов", а скорее модулей. И эти модули явно регистрируются на старте приложения. Так что всегда можно средствами VS найти какой сервис будет активирован при запросе какого-либо интерфейса. Никаких регистраций в конфиг-файлах, только в коде.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Lazin, Вы писали:
L>>Ну обычно у нас не бывает возможности использовать машины с бесконечным объемом памяти, поэтому приходится использовать ограниченные очереди для акторов, а когда ограниченная очередь переполнена, она блокируется.
V>Да, поэтому рядом я написал: V>
V>В любом случае выгребать сообщения из общих очередей в нагрузочных сценариях надо обязательно — об это спотыкаешься сразу.
Сразу выгребать оказывается надо, ты посмотри на него! Допустим у нас есть акторы Foo и Bar. Foo посчитал что-то и пытается записать это в очередь Bar, но она переполнена, потому что Bar не забирает оттуда сообщения, а не забирает он их оттуда потому что не может записать сообщение в очередь Foo, который ... В принципе цепочка может быть произвольной длины и даже может пересекать границы отдельных машин. Нет ничего невозможного
V>Этот момент как-то не на поверхности, но его быстро обнаруживаешь. Но на уровне конкретного модуля, который не успевает разгребать личные сообщения, затем уже можно делать диагностику. И кстати, если очередь построена на интрузивном способе, без дополнительных узлов-носилетей логики списка, какой смысл ограничивать ее длину? Если сообщение УЖЕ создано, (а оно обязательно создано ПЕРЕД отсылкой) то прилепить ее в конец такой очереди ничего не стоит.
Смысл ограничивать длину в том, чтобы клиент, который смог добавить сообщение в очередь, в том случае если ему не мешать, добавит туда еще одно и еще... Bounded очереди это простой и эффективный способ организовать back-pressure на producer-а.
V>======================== V>Например, если речь об асинхронном логировании при максимальном уровне логгирования. Тогда надо как-то изворачиваться, например, ренедрить лог-сообщения в буфер в памяти предварительно, т.е., чтобы кол-во операций IO не соответствовало 1:1 к кол-ву сообщений логирования, а записывать их пачками с неким коэф (брали порядка тысячи). Заметно снижает нагрузку на систему в целом. И вообще, вот этот способ передачи "пачками", даже когда речь о передаче сообщений м/у потоками — он самый эффективный, бо постоянное обращение к АПИ ОС или даже просто interlocked-операциям в одном месте снижает эффективность обращения к совсем другому АПИ ОС в другом месте. Например, за одну операцию на lock-free очереди разгребающий поток может получить все имеющиеся сообщения на данный момент (просто голову списка, обнулив shared-переменную через CAS), и потом разбирать пачку сообщений в цикле из локальной переменной-курсора без каких-либо тяжеловесных interlocked-операций. Если примененаа фильтрация этой пачки сообщений, то результат фильтрации чанка сообщений так же лучше прилепить в другую очередь целиком через одну interlocked операцию, вместо "ленивой" фильтрации и посылки резльтата в такую очередь по 1-му сообщению.
То, что ты описал, зовется алгоритмом Нагла, ему сто лет в обед, но применение этого алгоритма для создания lock-free очереди, это что-то новое для меня
Здравствуйте, vdimas, Вы писали:
Кё>>- в actor-based архитектуре очень легко получить дедлок; V>Считается ровно наоборот — акторы избавляют от присущему многопоточному ООП склонности к дедлокам. Как можно получить дедлок в асинхронной среде??? Только если ты намеренно отошел от асинхронности и ожидаешь в вечном цикле некоего конкретного события синхронно. Иначе никак...
Например объект выслал асинхронное сообщение и ждет ответа, а клиент умер и не отвечает. Или ждет в свою очередь другого ответа, который не будет выслан пока этот ответ не придет. Или из-за бага (программист забыл отправить ответ в ветке else) — при этом сам актер остается жив и продолжает отвечать другим, и просто вот этого конкретного клиента он своим багом “подвесил”. Дедлоки там не такие, как в многопоточности, не обязательно приводящие к подвисанию всей системы, и от этого не всегда сразу заметны. В актерах дедлок это ошибка в архитектуре, сделать ее легко.
Кё>>Но по сравнению с трудноуловимыми race condition это пустяки, если честно. V>??? V>Не сталкивались ни разу в своей системе. Сдается, у вас была не полноценная система акторов.
Я имел ввиду по сравнению с race condition при многопоточности. В актерах само собой их не бывает.
Здравствуйте, WolfHound, Вы писали:
WH>Короче модель каналов из сингулярити наше все. WH>А если еще и язык поддерживает проверку протоколов, то все совсем хорошо получается.
Эта модель называется Communicating Sequential Processes и они с актерами взаимозаменяемы, одно можно реализовать через другое. Каналы например моделируются как отдельные актеры с собственной очередью сообщений, и все, никакого протаскивания сендера и можно спрашивать их в произвольном порядке и контроллировать последовательность и статически анализировать. И наоборот, беспорядочное месиво сообщений в CSP моделируется самоограничением в один канал на процесс, который будет принимать все данные. Все проблемы которые ты описал это неумение готовить.
Здравствуйте, Буравчик, Вы писали:
Б>Какие языки/библиотеки использовались? Б>Удобно ли сопровождать (понимать, расширять, изменять) такие системы? Б>Какие есть минусы и плюсы actor-based? Б>Для чего actor-based стоит применять, а для чего нет?
Во первых, акторы — это частный случай dataflow, в том смысле, что у актора единственный порт для сообщений,
а у узла dataflow их может быть несколько, и срабатывание происходит, когда сообщения пришли на все порты
(в точности как в сетях Петри). Так что может быть, задача плохо ложится на акторы, но хорошо ложится на
dataflow.
Во вторых, модель dataflow имеет много разновидностей. Я для себя набросал здесь
классификацию узлов и каналов,а разновидностей будет почти как декартово произведение.
Так что сначала решите, какая именно модель вам подходит, а потом под нее подбирайте реализацию библиотеки.
Вообще-то я убежден, что для любой практической задачи можно подобрать адекватную разновидность dataflow модели, так что применять можно везде.
Проблема обычно в том, что большинство библиотек реализуют вполне конкретную разновидность модели, которая когда-то понадобилась
автору для конкретной задачи, в результате трудно отсеять необходимое от ненужных в другой задаче фич. Так что лучше делать библиотеку
под себя. Это не так сложно, как кажется. Существующие библиотеки объемны именно в силу специфичности, которая вам может и не понадобится.
Компактной неспецифической библиотеки я нигде не нашел, поэтому написал свою — df4j. Пользуясь ею как базисом, можно
добавлять любые варианты узлов и каналов под специфические нужды.
Основной плюс dataflow — распараллеливание на все наличное число процессоров без изменение программы. Минус — усложнение отладки, когда что-то виснет, и не сразу понятно, почему.
Здравствуйте, Кодёнок, Вы писали:
Кё>Эта модель называется Communicating Sequential Processes и они с актерами взаимозаменяемы, одно можно реализовать через другое. Каналы например моделируются как отдельные актеры с собственной очередью сообщений, и все, никакого протаскивания сендера и можно спрашивать их в произвольном порядке и контроллировать последовательность и статически анализировать. И наоборот, беспорядочное месиво сообщений в CSP моделируется самоограничением в один канал на процесс, который будет принимать все данные. Все проблемы которые ты описал это неумение готовить.
Конечно. Конечно.
А еще это можно организовать на мютексах, семафорах и черт знает, чем еще.
Только по запросу selective receive ссылка на его проблемы висит второй в гугле. А это что-то да значит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>В каждом акторе живет свой поток.
"Поток" может быть логический, примерно как поток событий для одного окошка GUI.
WH>То что некоторые рантаймы могут шарить один поток ОС между несколькими акторами или перекидывать один актор между несколькими потоками ОС не меняет того что у каждого актора есть свой личный поток в котором происходит вся работа с состоянием актора.
Ну и чем это отличается от обычной событийной модели с т.з. конкретного актора? Если низлежащая система, например, гарантирует, что конкретному актору приложения будут приходить ровно по 1-му, и следующее не придет до тех пор, пока не вернется предыдущий вызов...
Например, акторы могут использовать конвейер обработки сообщений. Это означает, что в процессе обработки сообщения M1 актор может варьировать поведение, которое будет использоваться для обработки следующего сообщения. В частности, это означает, что он может начать обработку ещё одного сообщения M2 до завершения обработки M1. На том основании, что актору предоставлено право использования конвейера обработки сообщений, ещё не означает, что он этот конвейер обязан использовать. Будет ли сообщение конвейеризовано или нет — относится к задачам технического компромисса.
В общем, от привычной событийной модели сам код актора отличается аж ничем, подробности даются инфраструктурой, но эти подробности не являются чем-то незначащими. Считай это еще одним взглядом на способ проектирования задач, где проектирование начинается с логики/политики доставки сообщений. Очень подходит к системам, где слово "протокол" не пустой звук. Самое оно.
V>>DI — это просто подход к проектированию/декомпозиции и не более. По конечному результату, то бишь по декомпозии как продукту дизайнера ПО сложно сказать, было там применено DI или нет. DI — это процесс, а не результат. С помощью этого процеса достигается лучшее SRP, это аксиома. С чем ты споришь-то? WH>С тем что для того чтобы соблюдать SRP нужен DI контейнер.
ОМГ... Издеваешься? Рассказываю медленно... Чтобы соблюдать SRP зачастую приходится применять процесс IoC, который транзитивно ведет к последующему обязательному DI. Я лишь указал начальные и конечные точки этого момента в процесе проектирования ООП-архитектуры, подразумевая, что ты и так должен был должен знать. Контейнер DI не является обязательным, ес-но, т.к. в жесткой архитектуре граф объектов можно построить руками. Ключевое во всём этом было то, что в технике DI граф строят не сами объекты в своих конструкторах, а некий внешний по отношению к объектам код. Я лишь поделился тем наблюдением, что заметной частью решения (то бишь трудоемкости) в реальном проекте оказались такие задачи, которые близки по-смыслу к задачам, решаемым DI-контейнерами. Почему и сослался на него, чтобы не расписывать подробно все эти задачи. В подобных контейнерах (напомню, если тебе настолько лень освежить) происходит преобразование декларативного описания зависимостей объектов в физический их граф. Т.е. при создании некоего целевого объекта DI-контейнер находит и ресолвит все зависимости к нему, создавая зависимые нужные объекты с свойствами для конкретно этой зависимости, к которым опять же ресолвятся зависимости и так рекурсивно/итеративно. Гибкости добавляет привязка зависимостей к контекстам. В терминах DI-контейнеров контексты — это не контексты исполнения, как в COM или дотнете, это как отдельные неймспейсы для самих зависимостей, то бишь много DI-контейнеров в одном. (Там еще много тонкостей, поиском по этому сайту найдешь подробные обсуждения на эту тему)
Просто удалось подобную функциональность реализовать с помощью той же самой подсистемы асинхронной передачи сообщений, бо у нас нет возможности и/или надобности "физически" подключать объекты напрямую друг к другу через ссылочные типы данных.
V>>DI как трюк разработки нет, есно, а упомянутые мною DI-контейнеры имеют самое непосредственное отношение. См. в той же статье вики тонкость насчет того, как акторы узнают друг о друге. ИМХО, это и есть самая интересная задача в акторах и она выглядит как естественное продолжение задачи, которую решают DI-контейнеры. Ты уже освежил, какую задачу решают эти контейнеры? Раньше их чаще называли IoC-контейнеры, что неграмотно (хоть и прижилось в кач-ве популярного мема... Но некоторые крупные конторы, например Microsoft, пользуются более корректной терминологией). WH>Я это лучше тебя знаю.
Угу, всё понимаю, но сказать не могу...
WH>>>4)Если бы ты потрудился понять о чем разговор, то ты бы не писал такие глупости. V>>Да я то понимаю и просто получаю фан от наблюдения за твоей работой мысли.. WH>А я за тем как ты не можешь понять, где модель системы, а где детали реализации.
Я прекрасно понял твою т.з., но оспариваю ее, считая, что ты неверно представляешь модель акторов. Прочитав твои аргументы я подозреваю тебя в, как бы сказать, странном понимании асинхронности как таковой. Ты накладываешь на асинхронность ограничения, которые не присущи определению асинхронности. Затем по цепочке ты умудрился наградить этими же ограничениями всю модель акторов.
Асинхронность означает лишь возврат из процедуры отсылки сообщения раньше, чем это сообщение может быть обработано и не означает ничего больше. Медитировать над этой фразой. "Внизу" под этим может быть что угодно, вплоть до фиберов и замены технологии очередей технологиями балансирования нагрузки на фиберах.
WH>Я просто нахожусь на более высоком уровне и вижу лес, а не деревья.
Пока что ты увидел вообще одно-единственное дерево — это собственное представление об асинхронности. Ты не застал DOS и явное управление прерываниями? Как же так оно раньше работало асинхронно вообще без выделенных потоков?
В общем, при попытке спросить, что ты там видишь, у нас случаются показательные ликбезы в банальностях какого-то совсем обидного начального уровня... Ты бы это.. сразу бы говорил, чтобы не растягивать бесполезный пинг-понг общения и чтобы не надо было вытаскивать клещами, что ты там прячешь за умным выражением лица.
V>>скрипа шестеренок... Но не боись, как показали предыдущие обсуждения, ты довольно быстро "нащупываешь" в чем дело и начинаешь говорить более-менее предметно. Взять хотя бы ту тему о выделении памяти областями или о синхронном GC. WH>То, что я говорил в той теме я понял несколько лет назад. WH>Только ты так и не понял, что именно я говорю.
Это ты мой пример не понял. Ты ведь по-сути предложил создавать фиктивный объект с предопределенными капабилитями, утверждая, что это избавит от явных объектов-аллокаторов, введение которых в модель и составляет якобы "ручное" управление памятью (хотя там автоматическое ес-но, просто вводится зависимость от экземпляра аллокатора). Но за своим "лесом" ты не увидел того дерева, что этот фиктивный объект будет играть в дизайне точно такую же роль, как экземпляр аллокатора. Как говорится, фейсом об тейбл. Надо же было решить эту задачу точно так же, разве что через синтаксический сахарок и претендовать на новизну и якобы отсутствие "ручного управления"... Был разачарован, увы... Любое ручное управление при наличии соотв. библиотек выглядит как декларативные зависимости, ничем не хуже синтаксического сахарка. И ведь озвучивал сие многократно, чтобы ты не попал в собственную ловушку... И Всё-равно попал... Потому что лучше выражать свои намеки явно, не затягивая фазу построения умного лица.
V>>1. Дождаться не значит блочить физический поток. WH>Опять путаешь поток ОС и поток актора. Это разные вещи. WH>Акторы про потоки ОС нихрена не знают. Ибо это деталь реализации. Не более того.
V>>2. Без подержки срочных собщений, то бишь исключительных ситуаций — это путь к дедлоку. Как известный пример: по приходу того же WM_QUIT бесполезно в обработчике некоего окна вечно ждать некоего специального сообщения, надо тупо освобождать ресурсы и выходить. WH>А это автору процесса решать, что нужно делать.
Чтобы ему решать, у него должна быть возможность выбирать. Если у тебя есть неблокирующие или асинхронные сокеты, то получить из них синхроннеы несложно, в отличие от наоборот, где придется асинхронную архитектуру городить ручками. Так же и для акторов — механизм доставки должен быть достаточно гибким, чтобы позволять выбирать или делать перевороты push<==>poll, как раз с целью фильтрации или упорядочивания сообщений (или дополнительного внутреннего роутинга и мало ли чего еще). Считай это разделением логики на логику совсем высокого уровня и на подробности. Логика самого высокого уровня хорошо работает как событийная модель из-за гибкости, универсальности и несклонности к дедлокам. Низкого уровня логика вполне может работать как набор синхронных poll-алгоритмов-продолжений (по крайней мере в синтаксисе языка на твоих каналах или yield return в C#), хотя извне это будет ес-но такой же push внутри poll самого высокго уровня текущего контекста исполнения (угу, именно такое оно — реактивное программирование изнутри, poll-циклы генерируют push сигналов). Хотя, по слухам, доносящимся из реактивного программирования, даже для низкого уровня push всё более интересен, а poll используется исключительно во внутренних механизмах пересечения контекстов, нейтральных к конкретной прикладной логике.
WH>Никто не мешает ждать более одного сообщения из разных каналов. Это если не маяться дурью с акторами.
В событийной модели это дается из коробки. Только мы всё еще имеем дело с акторами и не паримся...
WH>А в случае с акторами ты описал selective receive.
Нет, я показал, что O(N) для selective receive в случае ожидания одного сообщения — это бред сивой кобылы. Хотя, если КАЖДОЕ сообщение доставать по selective receive, то да-а-а... то нафига тебе асинхронность вообще? При чем тут тогда акторы?
V>>Поэтому каждую такую последовательность можно выделить в независимый алгоритм-продолжение, дергающийся в произвольные моменты, то бишь асинхронно извне, но синхронно внутри себя. WH>Те мы дожидаемся, когда поток актора зависнет на ожидании следующего сообщения и вызываем код для данного сообщения. WH>Правда, что делать в твоей моделе если актор в данный момент не готов принять это сообщение загадка.
Да я вижу, что асинхронность вообще для тебя загадка... А что я делаю, если у меня есть данные, а сокет еще не готов их принять? Неужели загадка? Некоторые так и ждут бесконечно на сокете, что порой провоцирует интересный пространственный дедлок двух компьютеров (!!!), получателя и отправителя. Лечил я и такое в синхронном программировании. Оба ендпоинта насытили свои стеки TCP и оба ждали завершения синхронной отправки данных, а выгребать сокеты некому. Потому что шел синхронный обмен достаточно большими по размеру сообщениями (порядка полумегабайт). Вот тебе смешной "пространственный" дедлок. Асинхронность+событийная модель всё это лечит на раз.
V>>Но это событийная модель, а модель синхронного разворота наподобие yield в C# или аналогичных по-сути каналов сингулярити менее гибка, хотя пойдет для несложных сценариев (повторяюсь уже). WH>Модель сингулярити является строгим надмножеством акторов.
Как тут говорят: "учу читать, дорого"...
Вообще-то речь была о развороте синхронного исходного кода в событийный/асинхронный. Это модель не сингулярити, а конкретного компилятора + низлежащего некоего механизма. Так вот, ограничения не в модели передачи сообщений как таковой (об этом речь не шла), а в том, что исходный синхронный код (как и его аналог yield return в C#) имеет ограничения. Если охота без ограничений — это надо не пользоваться подобными синтаксическими плюшками, а пользовать тот же IEnumerable-интерфейс напрямую или же вызывать АПИ твоей Сингулярити напрямую без поддержки каналов в синтаксисе языка... От существующих других асинхронных АПИ это ничем не будет отличаться, увы. Пайпы известны мильон лет. В т.ч. неблокирующие.
V>>И опять же, корректное освобождение ресурсов продолжений в случае простого подвисания ... WH>И ты опять завис на деталях реализации. WH>Леса не видишь.
Э нет, по вопросам корректной работы "продолжений" народ диссеры пишет, это нифига не незначащие детали. И как раз актуально это всё лишь в асинхроной среде. Львиная доля прикладной логики автоматом переезжает на инфраструктуру за счет комбинаторного сочетания политик взаимодействующих подсистем.
V>>Гы-гы, это звучит как аналогичное для стандартного ООП: "нет никакой проблемы соединять объекты друг с другом, просто через вызовы методов, установки св-в или через аргументы конструктора". Так для чего же тогда нужны DI-контейнеры? Особенно там, где SRP во главе угла? WH>Так они и не нужны. WH>Это костыль для ООП.
Нужны-нужны. Спроси у АВК, он тебе растолкует, если не понимаешь. Это считай полу-Пролог. Иногда ручки устанут объекты вручную соединять, легче декларативно указать зависимости. Особенно если такое построение неизвестно в compile-time. Кстати, для не-ООП я подобного инструмента не видел, везде еще больше ручками приходится. Если речь не о самом Прологе, есно.
M>>Тут Wolfhound загоняется насчет selective receive, и я даже знаю, какую ссылку он держит в загашнике. Только вот он работает уже 20 лет в промышленных масштабах, WH>Ты так говоришь как будто в той ссылке не правда, написана. WH>И это люди нарвались на практике. И напридумывали кучу подходов как это побороть.
Люди на практике нарываются, на что угодно, когда гоняют любую систему на пределе возможностей.
M>>а Singularity с каналами не видно просто тупо нигде. WH>Пошла демагогия.
Пошли факты
M>>Но, естественно, именно это является труъ подходом. WH>Это подход с точки зрения модели системы является более устойчивым к всяким бякам. WH>В частности он не сваливается в O(N^2) на ровном месте.
V>>В любом случае выгребать сообщения из общих очередей в нагрузочных сценариях надо обязательно — об это спотыкаешься сразу.
L>Сразу выгребать оказывается надо, ты посмотри на него!
Не понял юмора. Я это написал рядом фактически сразу как обнаружились заинтересованные собеседники.
L>Допустим у нас есть акторы Foo и Bar. Foo посчитал что-то и пытается записать это в очередь Bar, но она переполнена, потому что Bar не забирает оттуда сообщения, а не забирает он их оттуда потому что не может записать сообщение в очередь Foo, который ... В принципе цепочка может быть произвольной длины и даже может пересекать границы отдельных машин. Нет ничего невозможного
Оба ендпоинта насытили свои стеки TCP и оба ждали завершения синхронной отправки данных, а выгребать сокеты некому. Потому что шел синхронный обмен достаточно большими по размеру сообщениями (порядка полумегабайт). Вот тебе смешной "пространственный" дедлок. Асинхронность+событийная модель всё это лечит на раз.
Да, дедлок все-равно возможен, если генерируется трафик больший чем техника способна вообще обрабатывать. Дык только обсуждаемые акторы здесь не при чем. Неспособна, значит неспособна. В любой архитектуре ПО.
L>Смысл ограничивать длину в том, чтобы клиент, который смог добавить сообщение в очередь, в том случае если ему не мешать, добавит туда еще одно и еще... Bounded очереди это простой и эффективный способ организовать back-pressure на producer-а.
Гы, ты описал простой и эффективный способ достичь банального дедлока и ничего больше. Это профанация любой асинхронности как она есть, ведь превращаешь асинхронный вызов в синхронный. Один тебе актуальный намек на эту тему: в протоколах VoIP в сигналинге бывают команды на уменьшение трафика и прочая дидагностика. Заметил как реагирует кач-во звука в Скайпе при изменении условий связи? Его протокол динамически меняет кодеки.
V>>======================== V>>Например, если речь об асинхронном логировании при максимальном уровне логгирования. Тогда надо как-то изворачиваться, например, ренедрить лог-сообщения в буфер в памяти предварительно, т.е., чтобы кол-во операций IO не соответствовало 1:1 к кол-ву сообщений логирования, а записывать их пачками с неким коэф (брали порядка тысячи). Заметно снижает нагрузку на систему в целом. И вообще, вот этот способ передачи "пачками", даже когда речь о передаче сообщений м/у потоками — он самый эффективный, бо постоянное обращение к АПИ ОС или даже просто interlocked-операциям в одном месте снижает эффективность обращения к совсем другому АПИ ОС в другом месте. Например, за одну операцию на lock-free очереди разгребающий поток может получить все имеющиеся сообщения на данный момент (просто голову списка, обнулив shared-переменную через CAS), и потом разбирать пачку сообщений в цикле из локальной переменной-курсора без каких-либо тяжеловесных interlocked-операций. Если примененаа фильтрация этой пачки сообщений, то результат фильтрации чанка сообщений так же лучше прилепить в другую очередь целиком через одну interlocked операцию, вместо "ленивой" фильтрации и посылки резльтата в такую очередь по 1-му сообщению.
L>То, что ты описал, зовется алгоритмом Нагла, ему сто лет в обед, но применение этого алгоритма для создания lock-free очереди, это что-то новое для меня
Нагль малость для другого, для увеличения полезной доли в трафике. Ведь, передавая по 1-му символу с учетом всех заголовков IP и низлежащего транспорта (ethernet или ISDN), мы получаем долю полезной нагрузки менее 1%. А здесь идет речь о кол-ве вызовов АПИ ОС. Мало того, что каждый вызов ОС, даже холостой, даже на простейшем примитиве ядерной синхронизации — семафоре, занимает сотни ns на моей почти топовой машине, дык еще после самого вызова происходит некий штраф на эффективность выполнения последующего юзерского кода (добавляющий порядка 100-200ns в общем), скорее всего из-за смены контекстов виртуальной памяти туда-сюда. Т.е. эти бесполезные ~1us на сообщение предлагалось размазать на много их. За ту же стоимость 1us можно отрендерить порядка нескольких мегабайт лога в памяти, если руки правильно растут.
Ну и ты не заметил еще важную вещь, никак к Наглю не относящуюся: ты можешь регулярно вызывать одни аспекты АПИ ОС из одного потока на многоядерной машине, скажем, вызывать в цикле простой опрос времени, а тормозить может где-то в совсем другом месте, то бишь минимальная стоимость ядерных вызовов ОС на совсем других потоках и ядрах процессора из-за тех первых вызовов возрастает. ИМХО, где-то что-то в процессе ядерных вызовов синхронизируется или постоянно обновляются данные, которые обязательно шарятся. Причем, на Линухах это проявляется ярче, чем в последних виндах (7-ка). Т.е. минимизировать кол-во ЛЮБЫХ вызовов АПИ ОС — благодарная задача само по себе. (Например, поэтому пришлось отказаться от потоковой библиотеки С++)
Ну и interlocked-операции тоже, хоть дешевле, но добавляют штрафов к эффективности кеша и сбрасывают конвейеры, поэтому максимум пропускной способности на межпотоковых lock-free очередях удалось выжать только в сценарии, когда одну очередь разгребает один поток и он "забирает" каждый раз на "свою сторону" все накопившиеся на текущий момент сообщения. А балансировка нагрузки в этом сценарии наиболее эффективна по модели master-slave потоков, где мастер-поток единолично выгребает ту самую очередь и посылает другим рабочим потокам сообщения только в случае, если сам плохо справляется, то бишь когда размеры забираемых каждый раз пачек возрастают. Ес-но для нормальной работы всей системы никакой тупой bounding не пойдет. Курить ПИД-управление. Реагировать, когда очередь уже насытилась, поздно — почки уже отлетели. Надо следить за производными и интегралом, то бишь средней нагрузкой и динамикой на её фоне, а обратная пропорциональная связь задает коэф. жесткости управления... Кстате, как раз на ПИД делал де-джиттер для миксера VoIP. Много потоков шлют пакеты потоку-миксеру, который регулирует длину линии задержки в зависимости от динамики условий. Для диспатчинга сообщений делал чуть более простое управление, только ИП, без Д, но там нагрузка многократно меньше, так что хватало простого сглаживания средней нагрузки и обратной пропорциональной связи для принятия решений, сколько дополнительных потоков брать из пула.
Здравствуйте, sergeyt4, Вы писали:
V>>А как ты это делаешь в более простом DI-контейнере? А исопльзуешь ли вообще подход DI? Например, используешь ли ты обычные события дотнета вне WinForms (или другого GUI)? А как ты в WinForms узнаешь, кто подпишется на твоё событие? ИМХО, подпишется кто угодно...
S>Вне форм события мы не используем.
Я так и предположил...
S>Именно потому что неизвестно, кто на них подпишется, и глядя на метод никогда не догадаешься, что он, оказывается, является обработчиком события от определенного класса.
Как всё запущено. ))
S>Мы используем вместо этого callback-интерфейс с одним методом. По нему легко отыскать подписчиков. (По сути event — это и есть интерфейс с одним методом, но анонимный.)
Угу, а если использовать лямбды и карринг, то анонимности еще больше.
S>Используем ли мы подход DI? трудно сказать. Возможно и используем, не зная, что теперь это так называется.
Используете. На интерфейсах с одним методом это тоже имеет право на жизнь. Просто выглядит.. как-то по джавовски, что ле... В Reflector'е есть возможность посмотреть использование чего угодно и эта возможность хорошо работает не только на интерфейсах, легко можно отловить, кто именно подписывается на события. Сейчас Reflector платный, но цена всё-таки смешная. И есть плагин к студии. В общем, рекомендую. ИМХО, события — это удобная замена однометодным интерфейсам, чтобы не засорять информационное пространство проекта...
S>Но идеология приложения, раздробленного на миллион независимых запчастей, которые чудесным образом собираются в одно при запуске, меня не устраивает. В нем крайне сложно разобраться — кто с кем и зачем взаимодействует, чтобы потом добавлять новый функционал или менять старый.
Разбираться здесь можно как обычно — через иерархии. На основе более простых собирать более сложные. На любом уровне иерархии должны быть юниты примерно одинакового уровня сложности — ровно такого, чтобы тебе было несложно с ними разбираться.
S>Видимо, нужна очень подробная документация. (Но кто ее поддерживать в актуальном состоянии-то будет?) Наши приложения конечно не монолитны, но и не состоят из большого числа мелких "атомов", а скорее модулей.
Ну дык модули могут иметь зависимость от других модулей. Лучше всего для борьбы со сложностью — это когда зависимости однонаправленные и образуют иерархию. Тогда можно рассматривать выделенные "слои" приложения, придумывая и используя терминологию внутри слоя. Как раз, чтобы сложные унутре вещи обзывались простыми понятиями.
S>И эти модули явно регистрируются на старте приложения. Так что всегда можно средствами VS найти какой сервис будет активирован при запросе какого-либо интерфейса. Никаких регистраций в конфиг-файлах, только в коде.
Вполне покатит, когда не стоит задача динамического построения неизвестного заранее графа объектов.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Lazin, Вы писали:
V>>>
V>>>В любом случае выгребать сообщения из общих очередей в нагрузочных сценариях надо обязательно — об это спотыкаешься сразу.
L>>Сразу выгребать оказывается надо, ты посмотри на него!
V>Не понял юмора. Я это написал рядом фактически сразу как обнаружились заинтересованные собеседники.
L>>Допустим у нас есть акторы Foo и Bar. Foo посчитал что-то и пытается записать это в очередь Bar, но она переполнена, потому что Bar не забирает оттуда сообщения, а не забирает он их оттуда потому что не может записать сообщение в очередь Foo, который ... В принципе цепочка может быть произвольной длины и даже может пересекать границы отдельных машин. Нет ничего невозможного
V>Ты не поверишь, но этот сценарий тоже был упомянут: http://www.rsdn.ru/forum/philosophy/4796651.1.aspx
V>Оба ендпоинта насытили свои стеки TCP и оба ждали завершения синхронной отправки данных, а выгребать сокеты некому. Потому что шел синхронный обмен достаточно большими по размеру сообщениями (порядка полумегабайт). Вот тебе смешной "пространственный" дедлок. Асинхронность+событийная модель всё это лечит на раз.
V>Да, дедлок все-равно возможен, если генерируется трафик больший чем техника способна вообще обрабатывать. Дык только обсуждаемые акторы здесь не при чем. Неспособна, значит неспособна. В любой архитектуре ПО.
Ну это один из вариантов, вариантов на самом деле тысячи С акторами очень даже возможен дедлок, в erlang-е возможен дедлок, если акторы могут ждать появления сообщений, то возможно ситуация, когда несколько акторов ждут сообщений друг от друга, но никто ничего не посылает. Это конечно проблема архитектуры, но и в обычном многопоточном программировании deadlock это как правило проблема архитектуры.
L>>Смысл ограничивать длину в том, чтобы клиент, который смог добавить сообщение в очередь, в том случае если ему не мешать, добавит туда еще одно и еще... Bounded очереди это простой и эффективный способ организовать back-pressure на producer-а.
V>Гы, ты описал простой и эффективный способ достичь банального дедлока и ничего больше. Это профанация любой асинхронности как она есть, ведь превращаешь асинхронный вызов в синхронный. Один тебе актуальный намек на эту тему: в протоколах VoIP в сигналинге бывают команды на уменьшение трафика и прочая дидагностика. Заметил как реагирует кач-во звука в Скайпе при изменении условий связи? Его протокол динамически меняет кодеки.
Актор, это очень легкий объект, размероп в пару сотен байт. Там не бывает сложного сигналинга как VoIP. Если код каждого актора будет знание о загруженности того актора, которому мы хотим отправить сообщение и мы должны будем писать код с учетом этой информации, то код будет либо очень и очень сложным, либо все просто будут тупо реализовывать ожидание в случае если актор загружен. В результате получится блокирующая очередь, реализованая через одно место.
V>>>======================== V>>>Например, если речь об асинхронном логировании при максимальном уровне логгирования. Тогда надо как-то изворачиваться, например, ренедрить лог-сообщения в буфер в памяти предварительно, т.е., чтобы кол-во операций IO не соответствовало 1:1 к кол-ву сообщений логирования, а записывать их пачками с неким коэф (брали порядка тысячи). Заметно снижает нагрузку на систему в целом. И вообще, вот этот способ передачи "пачками", даже когда речь о передаче сообщений м/у потоками — он самый эффективный, бо постоянное обращение к АПИ ОС или даже просто interlocked-операциям в одном месте снижает эффективность обращения к совсем другому АПИ ОС в другом месте. Например, за одну операцию на lock-free очереди разгребающий поток может получить все имеющиеся сообщения на данный момент (просто голову списка, обнулив shared-переменную через CAS), и потом разбирать пачку сообщений в цикле из локальной переменной-курсора без каких-либо тяжеловесных interlocked-операций. Если примененаа фильтрация этой пачки сообщений, то результат фильтрации чанка сообщений так же лучше прилепить в другую очередь целиком через одну interlocked операцию, вместо "ленивой" фильтрации и посылки резльтата в такую очередь по 1-му сообщению.
L>>То, что ты описал, зовется алгоритмом Нагла, ему сто лет в обед, но применение этого алгоритма для создания lock-free очереди, это что-то новое для меня
V>Нагль малость для другого, для увеличения полезной доли в трафике. Ведь, передавая по 1-му символу с учетом всех заголовков IP и низлежащего транспорта (ethernet или ISDN), мы получаем долю полезной нагрузки менее 1%. А здесь идет речь о кол-ве вызовов АПИ ОС. Мало того, что каждый вызов ОС, даже холостой, даже на простейшем примитиве ядерной синхронизации — семафоре, занимает сотни ns на моей почти топовой машине, дык еще после самого вызова происходит некий штраф на эффективность выполнения последующего юзерского кода (добавляющий порядка 100-200ns в общем), скорее всего из-за смены контекстов виртуальной памяти туда-сюда. Т.е. эти бесполезные ~1us на сообщение предлагалось размазать на много их. За ту же стоимость 1us можно отрендерить порядка нескольких мегабайт лога в памяти, если руки правильно растут.
Nope, он именно для того, чтобы кол. операций ввода/вывода не соотв. 1:1 количеству сообщений. Пока устройство ввода/вывода занято — накапливаем сообщения, как только оно освободилось — пушим все что накопили, либо столькло сколько возможно спушить за один раз, а если устройство не занято и пришло одно сообщение — пушим одно сообщение. Просто если речь идет об акторах, то этот батчинг сообщений должен делаться библиотекой а не кодом актора явным образом, это во превых, а во вторых, большую часть времени, акторы будут работать не с пиковой загрузкой, что естественно, поэтому сообщения будут отправляться и приниматься по одному. Тупой батчинг просто просадит в этом случае латентность и не даст заметного прироста производительности, а Нагл как раз позволяет в случае низкой нагрузки кидаться отдельными сообщениями, а в случае высокой — пачками сообщений, жертвуя латентностью.
V>Ну и ты не заметил еще важную вещь, никак к Наглю не относящуюся: ты можешь регулярно вызывать одни аспекты АПИ ОС из одного потока на многоядерной машине, скажем, вызывать в цикле простой опрос времени, а тормозить может где-то в совсем другом месте, то бишь минимальная стоимость ядерных вызовов ОС на совсем других потоках и ядрах процессора из-за тех первых вызовов возрастает. ИМХО, где-то что-то в процессе ядерных вызовов синхронизируется или постоянно обновляются данные, которые обязательно шарятся. Причем, на Линухах это проявляется ярче, чем в последних виндах (7-ка). Т.е. минимизировать кол-во ЛЮБЫХ вызовов АПИ ОС — благодарная задача само по себе. (Например, поэтому пришлось отказаться от потоковой библиотеки С++)
Минимизация количества ядерных вызовов это всегда благородная задача, даже в однопоточных приложениях Вообще, мысль от акоторов уже достаточно далеко уже ушла, не находишь?
V>Ну и interlocked-операции тоже, хоть дешевле, но добавляют штрафов к эффективности кеша и сбрасывают конвейеры, поэтому максимум пропускной способности на межпотоковых lock-free очередях удалось выжать только в сценарии, когда одну очередь разгребает один поток и он "забирает" каждый раз на "свою сторону" все накопившиеся на текущий момент сообщения. А балансировка нагрузки в этом сценарии наиболее эффективна по модели master-slave потоков, где мастер-поток единолично выгребает ту самую очередь и посылает другим рабочим потокам сообщения только в случае, если сам плохо справляется, то бишь когда размеры забираемых каждый раз пачек возрастают. Ес-но для нормальной работы всей системы никакой тупой bounding не пойдет. Курить ПИД-управление. Реагировать, когда очередь уже насытилась, поздно — почки уже отлетели. Надо следить за производными и интегралом, то бишь средней нагрузкой и динамикой на её фоне, а обратная пропорциональная связь задает коэф. жесткости управления... Кстате, как раз на ПИД делал де-джиттер для миксера VoIP. Много потоков шлют пакеты потоку-миксеру, который регулирует длину линии задержки в зависимости от динамики условий. Для диспатчинга сообщений делал чуть более простое управление, только ИП, без Д, но там нагрузка многократно меньше, так что хватало простого сглаживания средней нагрузки и обратной пропорциональной связи для принятия решений, сколько дополнительных потоков брать из пула.
Тоесть ты предлагаешь использовать ПИД регулятор для балансировки нагрузки между процессорами? В таком случае, ты должен знать, что ПИД регулятор обычно включается в контур обратной связи, то бишь ты должен уметь влиять на producer-а сообщений, а тупоой bounding это как-раз и есть такая обратная связь, только вместо ПИД-регулятора у нас будет нелинейность — насыщение Вообще, конечно интересный ход мысли, никогда не думал в таком ключе о системе producer/consumer
Здравствуйте, Mamut, Вы писали:
M>Люди на практике нарываются, на что угодно, когда гоняют любую систему на пределе возможностей.
Эффект проявляется на 10% процентах от предельной нагрузки.
Достаточно одного кратковременного всплеска.
И приплыли.
M>>>а Singularity с каналами не видно просто тупо нигде. WH>>Пошла демагогия. M>Пошли факты
Нет. Демагогия.
Ибо сперва добейся не аргумент.
И тут это в двойне не аргумент.
Ибо если бы мелкософт начал продвигать сингулярити то сейчас бы использовали ее, а не ерланг.
M>Уже и фантазии про ровные места пошли
Кратковременный всплеск при 10%ной нагрузки это ровное место.
M>Это намек на то, что пропагандируемые тобой подходы на практике днем с огнем не. http://blogs.jetbrains.com/dotnet/2012/06/jetbrains-and-nemerle/
"Core developers behind a project called Nemerle" это я, Влад и Хардкейс.
Так что через пару тройку лет мы еще посмотрим, что будет более распространено. N2 или ерланг.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>>>а Singularity с каналами не видно просто тупо нигде. WH>>>Пошла демагогия. M>>Пошли факты WH>Нет. Демагогия. WH>Ибо сперва добейся не аргумент. WH>И тут это в двойне не аргумент. WH>Ибо если бы мелкософт начал продвигать сингулярити то сейчас бы использовали ее, а не ерланг.
Бгггг. И этот человек мне рассказывает про демагогию. Ну-ну
M>>Уже и фантазии про ровные места пошли WH>Кратковременный всплеск при 10%ной нагрузки это ровное место.
Нет, не ровное.
M>>Это намек на то, что пропагандируемые тобой подходы на практике днем с огнем не. WH>http://blogs.jetbrains.com/dotnet/2012/06/jetbrains-and-nemerle/ WH>"Core developers behind a project called Nemerle" это я, Влад и Хардкейс. WH>Так что через пару тройку лет мы еще посмотрим, что будет более распространено. N2 или ерланг.
Здравствуйте, Mamut, Вы писали:
M>Бгггг. И этот человек мне рассказывает про демагогию. Ну-ну
Это не демагогия.
Это факты.
Только объявление о том, что JetBrains берет немерле значительно подняло интерес к языку.
А тут мы сравниваем ерланг который поддерживает ериксон и сингулярити которую не поддерживает никто.
WH>>Кратковременный всплеск при 10%ной нагрузки это ровное место. M>Нет, не ровное.
Абсолютно ровное.
Ибо кратковременный всплеск это штатное явление.
Кратковременные всплески должны рассасываться сами даже на 90%ной средней нагрузке.
А тут на 10%ной все падает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>Бгггг. И этот человек мне рассказывает про демагогию. Ну-ну WH>Это не демагогия. WH>Это факты. WH>Только объявление о том, что JetBrains берет немерле значительно подняло интерес к языку. WH>А тут мы сравниваем ерланг который поддерживает ериксон и сингулярити которую не поддерживает никто.
Тут мы сравниваем реально используемый в промышленных масштабах язык и сказки про технологии, которые никто в глаза не видел в промышленности. Приходи через три года.
Ах, да, что у JetBrains есть промышленного масштаба кроме IDE?
Здравствуйте, vdimas, Вы писали:
V>Чтобы оно сваливалось в O(N^2), надо чтобы адрес каждый раз получался минимум за O(N) и сообщение доставлялось (т.е. ресолвился адрес) тоже за O(N), где N — кол-во акторов... а так-то обе операции выполнимы за O(1).
Я несколько раз явно сказал, что selective receive приводит к O(N^2) где N количество сообщений в очереди актора.
V>Цимус в том, что нет никакого смысла посылать сообщение конкретному каналу в общем случае. Даже если в Сингулярити это на уровне языка видится именно так, реально это может происходить не так. Асинхронная отсылка может идти в общую очередь с привязанным идентификатором канала, а эта очередь затем может разгребаться на пуле потоков.
Аааааааааа!
Мужики всеми силами придумывали модель, которая не имеет бутылочного горлышка, а ты его искусственно создал.
V>Почему так? Предлагаю порассуждать на предмет как времени жизни каналов,
Никаких проблем с этим нет. Просто убиваем канал, когда подохли оба конца и все.
V>так и на предмет того, что канал вовсе не обязан иметь выделенный физический поток-обработчик сообщений.
Это тоже ни разу не проблема.
V>Асинхронная модель поверх событийной (то бишь на пуле потоков) хороша тем, что не требует обязательного физического потока на каждый актор. Хотя, никто не запрещает акторам создавать такие потоки для своих внутренних нужд. Просто я не представляю работу на каналах обработчиков хотя бы для тысячи подключений, если к каждому подключению привязывается минимум 5 акторов для логики всего приложения...
То, что у тебя серьезные проблемы с фантазией это я давно понял.
Когда процесс подвисает на ожидании сообщения он просто становится не активным и не требует к себе никакого внимания. Совсем. Только память занимает.
Когда в тот канал, на котором висит процесс, пришло сообщение процесс встает в очередь своего шедуллера.
Каждый шедуллер живет на своем физическом потоке.
Если шедуллеру нечего делать он начинает воровать готовые к исполнению процессы у занятых шедуллеров.
V>И на последок как пример — асинхронный ввод/вывод в виндах в сокеты.
1)Очень примитивный пример. Там selective receive нет. Так что и O(N^2) не появляется.
2)Весь этот код упирается в пропускную способность сети. Так что тут вообще говорить не о чем.
Ты блин как мамут. Он тоже доказывал что ерланг работает быстро на основе теста который только и делал что IO.
V>Скорее намек на то, что в последнее время ты больше обсуждаешь несуществующие в реальном воплощении и необкатанные на практике вещи.
Я просто могу анализировать различные решения.
И поэтому вижу, какие у них есть проблемы.
А ты даже не можешь понять, откуда у selective receive появляется O(N^2). Это даже мамут понимает. Хотя и пытается всех убедить, что это ерунда.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>Ну и чем это отличается от обычной событийной модели с т.з. конкретного актора? Если низлежащая система, например, гарантирует, что конкретному актору приложения будут приходить ровно по 1-му, и следующее не придет до тех пор, пока не вернется предыдущий вызов...
Так это и есть логический поток.
Просто разбор очереди сообщений написан не явно.
V>
V>Например, акторы могут использовать конвейер обработки сообщений. Это означает, что в процессе обработки сообщения M1 актор может варьировать поведение, которое будет использоваться для обработки следующего сообщения. В частности, это означает, что он может начать обработку ещё одного сообщения M2 до завершения обработки M1. На том основании, что актору предоставлено право использования конвейера обработки сообщений, ещё не означает, что он этот конвейер обязан использовать. Будет ли сообщение конвейеризовано или нет — относится к задачам технического компромисса.
Чем дальше, тем фееричнее.
Если у нас обработка сообщений независима, то зачем их вообще обрабатывать одним процессом?
Где смысл?
V>Очень подходит к системам, где слово "протокол" не пустой звук. Самое оно.
Этим системам неизмеримо лучше подходит модель сингулярити.
Там протоколы описаны явно. И проверяются аж компилятором во время компиляции.
V>ОМГ... Издеваешься? Рассказываю медленно... Чтобы соблюдать SRP зачастую приходится применять процесс IoC, который транзитивно ведет к последующему обязательному DI.
Не приходится. Все дальнейшие рассуждения идут в мусор.
V>Я прекрасно понял твою т.з., но оспариваю ее, считая, что ты неверно представляешь модель акторов. Прочитав твои аргументы я подозреваю тебя в, как бы сказать, странном понимании асинхронности как таковой. Ты накладываешь на асинхронность ограничения, которые не присущи определению асинхронности. Затем по цепочке ты умудрился наградить этими же ограничениями всю модель акторов.
Это ты не понимаешь, что эти ограничения есть.
Если у актора есть состояние, то сообщения нужно обрабатывать в некоторой последовательности.
Иначе будут гонки и хана состоянию.
И если ты организуешь эту самую последовательность, то ты сразу получаешь поток исполнения.
V>Пока что ты увидел вообще одно-единственное дерево — это собственное представление об асинхронности. Ты не застал DOS и явное управление прерываниями? Как же так оно раньше работало асинхронно вообще без выделенных потоков?
Ох. Совершенно не можешь отделить модель от деталей реализации.
Ну совсем.
V>Чтобы ему решать, у него должна быть возможность выбирать.
В моей модели она есть.
V>Нет, я показал, что O(N) для selective receive в случае ожидания одного сообщения — это бред сивой кобылы. Хотя, если КАЖДОЕ сообщение доставать по selective receive, то да-а-а... то нафига тебе асинхронность вообще? При чем тут тогда акторы?
При запросе selective receive в гугле его проблемы описаны во второй из более чем 30 миллионов ссылок.
Подумай об этом.
V>Да я вижу, что асинхронность вообще для тебя загадка... А что я делаю, если у меня есть данные, а сокет еще не готов их принять? Неужели загадка? Некоторые так и ждут бесконечно на сокете, что порой провоцирует интересный пространственный дедлок двух компьютеров (!!!), получателя и отправителя. Лечил я и такое в синхронном программировании. Оба ендпоинта насытили свои стеки TCP и оба ждали завершения синхронной отправки данных, а выгребать сокеты некому. Потому что шел синхронный обмен достаточно большими по размеру сообщениями (порядка полумегабайт). Вот тебе смешной "пространственный" дедлок. Асинхронность+событийная модель всё это лечит на раз.
Бред какой-то.
На каналах сингулярити такое не может произойти теоритически.
Ибо его ендпоинты не могут одновременно оказаться в состоянии, когда они могут отправлять сообщения.
V>Нужны-нужны. Спроси у АВК, он тебе растолкует, если не понимаешь.
Я с ним работал. Он очень любит архитектурить на ровном месте.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Кодёнок, Вы писали:
Кё>Я имел ввиду по сравнению с race condition при многопоточности. В актерах само собой их не бывает.
Тут еще вопрос в том, что считать race condition.
Ибо если два актора отправляют сообщение третьему, то неизвестно какое сообщение придет первым. Это тоже race condition.
Да даже сообщения одного актора могут прийти не в том порядке, в котором их посылали. И это тоже race condition.
Чтобы избавить себя от race condition нужно использовать модель каналов из сингулярити.
Там чтобы нарваться на race condition нужно явно в коде, написать ожидание на более чем одном канале.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Иначе никак...
