Здравствуйте, Курилка, Вы писали:

К>Здравствуйте, eao197, Вы писали:

E>>Правильно ли я понимаю, что если в Эрланге процессу пришло несколько однотипных сообщений, то Эрланг не гарантирует их выборку в receive в порядке ФИФО?

К>ФИФО гарантируется для пары "автор-получатель", язык динамически типизированный, так что типы сообщений значения не имеют (если не учитывать более хитрые вещи аля вложенные receive).

Ну тогда всё встаёт на свои места, я уж думал, что я совсем что-то важное упускал из вида, если Эрланг не гарантирует хоть какое-то ФИФО.
Аааа... понятно, почему он только per-producer fifo гарантирует, в сети не получится реализовать более строгий fifo. Хотя на SMP я бы предпочёл causal fifo.
Но даже с per-producer fifo будут проблемы при динамической балансировке нагрузке. Допустим переслали агнета на новый процессор. Дальше начинаем ему вслед пересылать сообщения, которые были отправлены ему ещё на старое место. Теперь надо эти сообщения, которые пошли вслед упорядочить с сообщениями, которые пошли этому агенту уже на новое место... Хммм... ну в общем случае это требует детектирования обще-системного quiescence point, что бы понять, что на старое место агенту сообщения уже не идут и не лежат ни в каких очередях в этой распределенной системе.

Кстати, Курилка, и все, кто работает с Эрланг и другими реализациями актёров или обмена сообщениями, как вы относитесь к идеи убрать любые гарантии ФИФО?

Здравствуйте, remark, Вы писали:

R>Кстати, Курилка, и все, кто работает с Эрланг и другими реализациями актёров или обмена сообщениями, как вы относитесь к идеи убрать любые гарантии ФИФО?

немного не в тему, может быть, но в высокоуровневых системах, построенных на обмене сообщениями, лично я всегда придерживался архитектур с более, чем одним потребителем, висящем на одной очереди (load balancing + failover), что автоматически отменяло возможность выдвигать требования обработки сообщений в порядке их генерации

Здравствуйте, remark, Вы писали:

R>Кстати, Курилка, и все, кто работает с Эрланг и другими реализациями актёров или обмена сообщениями, как вы относитесь к идеи убрать любые гарантии ФИФО?

Допустим, агент управляет каким-то устройством (PCSC-ридером или GSM-модемом), подключенным к компьютеру. Агенту последовательно отправляют сообщения -- reset_device, set_params, write_data. А приходят они в виде set_params (когда устройство еще не проинициализировано), write_data и reset_device.

Здравствуйте, eao197, Вы писали:

E>Допустим, агент управляет каким-то устройством (PCSC-ридером или GSM-модемом), подключенным к компьютеру. Агенту последовательно отправляют сообщения -- reset_device, set_params, write_data. А приходят они в виде set_params (когда устройство еще не проинициализировано), write_data и reset_device.

имхо, это одна их те ситуаций, которая разруливается на уровне требований типа "нельзя выдавать новый ордер на устройство, если уже есть какой-либо ордер на то же устройство в статусе pending"

Здравствуйте, C0s, Вы писали:

C0s>имхо, это одна их те ситуаций, которая разруливается на уровне требований типа "нельзя выдавать новый ордер на устройство, если уже есть какой-либо ордер на то же устройство в статусе pending"

Тот, кто генерирует управляющие сообщения для устройства может не иметь понятия о статусе ордеров. Он может просто знать, что устройство находится в его полном распоряжении и он может отправлять те команды, которые считает нужным. А делать на сообщениях двухфазные взаимодейтсвия типа запрос-ответ, временами, может быть слишком большим гемороем.

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, eao197, Вы писали:

E>>Допустим, агент управляет каким-то устройством (PCSC-ридером или GSM-модемом), подключенным к компьютеру. Агенту последовательно отправляют сообщения -- reset_device, set_params, write_data. А приходят они в виде set_params (когда устройство еще не проинициализировано), write_data и reset_device.

C0s>имхо, это одна их те ситуаций, которая разруливается на уровне требований типа "нельзя выдавать новый ордер на устройство, если уже есть какой-либо ордер на то же устройство в статусе pending"


Это уже не асинхронный обмен сообщениями. Это уже RPC какой-то.
Это искуственное замедление системы. Зачем отправителю ждать, если он может сгенерировать сообщение сейчас. Зачем обязательно генерировать дополнительное подтверждение обработки предыдущего сообщения, зачем теперь занового шедулить агента отправителя, что бы он только сейчас сгенерировал второе сообщение. Плюс латентность существенно возростает. Фактически получается, что всё работает в одном потоке — вначале поток обрабатывает отправителя, потом устройство, потом опять отправителя и т.д.
Плюс это существенно снижает загрузку системы собщениями, а известно, что такие системы работают на полной мощности, только когда есть достаточный запас сообщений в системе.
Я не говорю, что такой подход сам по себе не имеет права на жизнь — зато во многих ситуациях он даёт большую простоту. Но это уж точно не то, о чём говорил thesz. Он говорил о ситуации когда у нас как раз все сообщения генерируются сразу.

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, remark, Вы писали:

R>>Кстати, Курилка, и все, кто работает с Эрланг и другими реализациями актёров или обмена сообщениями, как вы относитесь к идеи убрать любые гарантии ФИФО?

C0s>немного не в тему, может быть, но в высокоуровневых системах, построенных на обмене сообщениями, лично я всегда придерживался архитектур с более, чем одним потребителем, висящем на одной очереди (load balancing + failover), что автоматически отменяло возможность выдвигать требования обработки сообщений в порядке их генерации


Такой паттерн тоже есть, но он не охватывает много ситуаций. Фактически тут имеется множество *отдельных* *независимых* запросов и нам просто надо получить лоад-балансинг.
Один контр-пример привёл eao197. Другой, например, GUI прогресс-баг, который получает сообщения для обновления прогресса. Если мы получим вначале сообщение о 80% прогрессе, а потом о 20% прогресса, то мы в достаточно затруднительном положении. ... Понятно, конечно, что всё можно разрулить руками...

Здравствуйте, eao197, Вы писали:

E>Тот, кто генерирует управляющие сообщения для устройства может не иметь понятия о статусе ордеров. Он может просто знать, что устройство находится в его полном распоряжении и он может отправлять те команды, которые считает нужным. А делать на сообщениях двухфазные взаимодейтсвия типа запрос-ответ, временами, может быть слишком большим гемороем.

выделенное жирным имхо, слишком сильное требование из разряда "хочу большого интеллектуализма и бесплатно"
не в том смысле, что он должен прямо-таки разбираться в ордерах, но просто быть готовым к быстрому синхронному ответу "заявка не принята, попробуйте позже".

а из выделенного курсивом не должно следовать, что отправляющий команды имеет право, в том числе, поломать устройство некорректной последовательностью команд

возможна реализация, которая скроет логику неломаемости внутрь, но это приведёт к тому, что часть ордеров будет тихо отклонена — это тоже имеет право на жизнь. примерно как, если ты нажмёшь на пульте телевизора одновременно кнопки "предыдущий канал" и "следующий канал", телевизор сделает либо одно, либо другое, либо пульт проигнорирует оба нажатия

в сущности, речь о том, где контроль ставить — на стороне отправителя или на стороне получателя

Здравствуйте, remark, Вы писали:

E>>>Допустим, агент управляет каким-то устройством (PCSC-ридером или GSM-модемом), подключенным к компьютеру. Агенту последовательно отправляют сообщения -- reset_device, set_params, write_data. А приходят они в виде set_params (когда устройство еще не проинициализировано), write_data и reset_device.

C0s>>имхо, это одна их те ситуаций, которая разруливается на уровне требований типа "нельзя выдавать новый ордер на устройство, если уже есть какой-либо ордер на то же устройство в статусе pending"

R>Это уже не асинхронный обмен сообщениями. Это уже RPC какой-то.
R>Это искуственное замедление системы

да нет, я совсем не о скорости, а о том, что реальные софтверные системы на определённом не низком уровне часто имеют определённые бизнес-требования и бизнес-ограничения.

R>Это искуственное замедление системы. Зачем отправителю ждать, если он может сгенерировать сообщение сейчас. Зачем обязательно генерировать дополнительное подтверждение обработки предыдущего сообщения, зачем теперь занового шедулить агента отправителя, что бы он только сейчас сгенерировал второе сообщение. Плюс латентность существенно возростает. Фактически получается, что всё работает в одном потоке — вначале поток обрабатывает отправителя, потом устройство, потом опять отправителя и т.д.

и там присутствует борьба за скорость, но всегда в соответствии с требованиями

в частности (и мне такое доводилось делать), если отправитель должен всегда иметь воможность быстро послать сообщение, но получатель не всегда должен его обрабатывать в силу определённых ограничений — пожалуйста, ставим контроль ограничений на получателя
доводилось также делать многоступенчатую обработку, при которой была цепочка сообщений и, соответственно, цепочка получателей, каждый из которых проверял определённые условия, делал определённую работу и мог отсечь выполнение при несоблюдении каких-то условий

Здравствуйте, C0s, Вы писали:

C0s>выделенное жирным имхо, слишком сильное требование из разряда "хочу большого интеллектуализма и бесплатно"
C0s>не в том смысле, что он должен прямо-таки разбираться в ордерах, но просто быть готовым к быстрому синхронному ответу "заявка не принята, попробуйте позже".

C0s>а из выделенного курсивом не должно следовать, что отправляющий команды имеет право, в том числе, поломать устройство некорректной последовательностью команд

C0s>возможна реализация, которая скроет логику неломаемости внутрь, но это приведёт к тому, что часть ордеров будет тихо отклонена — это тоже имеет право на жизнь. примерно как, если ты нажмёшь на пульте телевизора одновременно кнопки "предыдущий канал" и "следующий канал", телевизор сделает либо одно, либо другое, либо пульт проигнорирует оба нажатия

C0s>в сущности, речь о том, где контроль ставить — на стороне отправителя или на стороне получателя

А если эти 2 агента разнесены по сети, что ж мы теперь не можем 2 сообщения сразу отправить, и обязательно ждать двойного раунд-трипа по сети...
На примере сети это просто более явно видно, но те же тенденции сохраняются и на одной машине.

Здравствуйте, C0s, Вы писали:

E>>Тот, кто генерирует управляющие сообщения для устройства может не иметь понятия о статусе ордеров. Он может просто знать, что устройство находится в его полном распоряжении и он может отправлять те команды, которые считает нужным. А делать на сообщениях двухфазные взаимодейтсвия типа запрос-ответ, временами, может быть слишком большим гемороем.

C0s>выделенное жирным имхо, слишком сильное требование из разряда "хочу большого интеллектуализма и бесплатно"

Мой опыт использования агентов как раз убеждает меня в том, что агенты и предназначены для достижения этой цели.

C0s>не в том смысле, что он должен прямо-таки разбираться в ордерах, но просто быть готовым к быстрому синхронному ответу "заявка не принята, попробуйте позже".

В принципе, этого может и не быть. Если агент-устройство диагностирует проблему, он может убить сам себя. Это спровоцирует агента-супервизора убить и тех, кто находится на связи с этим агентом (как раз генератора событий). А это спровоцирует еще одного агента-супервизора на рестарт всех ранее убитых агентов. Вполне нормальное, имхо, поведение для случаев, когда сбой в работе с оборудованием -- явление редкое и успешно лечится рестартом, или же не лечится программным путем вообще.

C0s>в сущности, речь о том, где контроль ставить — на стороне отправителя или на стороне получателя

Логика отправителя может очень сильно зависеть от того, как будет вести себя получатель. Хороший пример привел remark с прогресс-баром. Еще один пример -- один агент обслуживает TCP/IP канал (контроль к записи/чтению и операции ввода/вывода), а второй готовит исходящие данные (например, режет большой поток на пакеты). Если агент-канал вдруг получит сообщения с данными не в том порядке, в котором они ему приходили, то ничего хорошего из этого не получится.

Здравствуйте, remark, Вы писали:

C0s>>немного не в тему, может быть, но в высокоуровневых системах, построенных на обмене сообщениями, лично я всегда придерживался архитектур с более, чем одним потребителем, висящем на одной очереди (load balancing + failover), что автоматически отменяло возможность выдвигать требования обработки сообщений в порядке их генерации

R>Такой паттерн тоже есть, но он не охватывает много ситуаций. Фактически тут имеется множество *отдельных* *независимых* запросов и нам просто надо получить лоад-балансинг.

я лишь имел в виду, что лучше всего иметь действительно независимые запросы. т.е. стремиться к этому ещё на уровне выработки бизнес-требований и системного анализа до разраработки

если не получается, то вводятся промежуточные обработчики, или кто-то на стороне первоначального отправителя, которые должны контролировать и отсекать сообщения, которые не могут быть обработаны.
опять же, бывают интересные случаи (опять же доводилось так делать), когда сообщения отправляются обратно в ту же очередь с выставлением delay на следующую попытку redelivery — годится тогда, когда есть надежда, что в будущем сообщение сможет быть обработано, т.к. текущие ограничения на его обработку носят лишь временный характер, и с вероятностью 99% через delay пройдут

R>Другой, например, GUI прогресс-баг, который получает сообщения для обновления прогресса. Если мы получим вначале сообщение о 80% прогрессе, а потом о 20% прогресса, то мы в достаточно затруднительном положении. ... Понятно, конечно, что всё можно разрулить руками...

здесь легко разруливается на стороне получателя — он просто игнорирует сообщения о прогрессе со значением, меньшим текущего уже установленного в форме прогресса

Здравствуйте, remark, Вы писали:

R>А если эти 2 агента разнесены по сети, что ж мы теперь не можем 2 сообщения сразу отправить, и обязательно ждать двойного раунд-трипа по сети...
R>На примере сети это просто более явно видно, но те же тенденции сохраняются и на одной машине.

на стороне получателя придётся ставить логику, которая будет игнорировать некоторые сообщения, либо откладывать их

Здравствуйте, C0s, Вы писали:

C0s>в частности (и мне такое доводилось делать), если отправитель должен всегда иметь воможность быстро послать сообщение, но получатель не всегда должен его обрабатывать в силу определённых ограничений — пожалуйста, ставим контроль ограничений на получателя
C0s>доводилось также делать многоступенчатую обработку, при которой была цепочка сообщений и, соответственно, цепочка получателей, каждый из которых проверял определённые условия, делал определённую работу и мог отсечь выполнение при несоблюдении каких-то условий

Если говорить о бизнес-требованях и высоком уровне, то тут, мне кажется, выгода от ФИФО становится ещё более явной.
Во-первых, ФИФО — это надмножество НЕФИФО, т.е., пожалуйста, делай синхронный запрос-ответ.
Но так же ФИФО позволяет реализовывать и другие паттерны. Один, мне кажется, ты сам привёл — "...если отправитель должен всегда иметь воможность быстро послать сообщение, но получатель не всегда должен его обрабатывать...", в этой ситуации требовалось ФИФО для этих быстро посланных сообщений?

Я не против того, что бы система предоставляла возможность сказать "для этого агента порядок не требуется", если она может реализовать что-то лучше для такого случая. Но в то же время для "высокоуровневой", "удобной" системы, я считаю обязательным так же и возможность задать гарантированный ФИФО. При этом ФИФО больше как выбор "по-умолчанию", а не ФИФО — как оптимизация.

По моему опыту, если идут "низходящие" сообщения (т.е. менеджер устройства посылает устройству) и сообщения типа "запрос", то тогда, в принципе, возможно делать какое-то высокоуровневое управление. Хотя зачастую это только лишняя работа.
Но если идут "восходящие" сообщения (т.е. устройство посылает кому-то — нижние уровни не должны знать о верхних) и/или сообщения типа "нотификация", то тут ФИФО необходимо, т.к. нижний уровень и/или нотификатор не знает даже есть ли там кто-то сверху, а при нотификациях бессмысленно ждать ответа — ну посылает агент-устройство нотификацию, что он детектировал, что связь с устройством разорвалась, ну и что ему делать потом с ответом? отменить разрыв соединения, если с верхнего уровня сказали "отменить"? Детектировал агент, что связь установлена — послал нотификацию, что установлена; детектировал что разоравана — послал, что разорвана. А обрабатывает там кто ещё предыдущие сообщения или нет — пофигу, главное — что бы сообщения "связь установлена", "связь разорвана" не перепутались местами. Плюс не этот агент выбирает время разрыва соединения, его тоже ставят перед фактом, что ему делать? Можно конечно сообщения складывать во внутренний вспомогательный буфер (кстати, обязательно в ФИФО порядке) и потом выдавать их, когда приходят ответы на предыдущие сообщения. Но попахивает уже маразмом...

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, remark, Вы писали:

R>>А если эти 2 агента разнесены по сети, что ж мы теперь не можем 2 сообщения сразу отправить, и обязательно ждать двойного раунд-трипа по сети...
R>>На примере сети это просто более явно видно, но те же тенденции сохраняются и на одной машине.

C0s>на стороне получателя придётся ставить логику, которая будет игнорировать некоторые сообщения, либо откладывать их

Я понимаю, что всё это можно сделать руками. Но что ты будешь делать в случае сетевого соединения? Правильно, восстанавливать ФИФО. Что ты будешь делать в случае с прогресс-баром? Правильно, восстанавливать ФИФО. Что ты будешь делать с сообщениями драйвера устройства? Правильно, восстанавливать ФИФО.
Я считаю, что этот паттерн настолко необходимый, что он должен быть просто по-умолчанию. При желании, если необходима скорость, то можно явно выборочно снизить требования до "произвольный порядок" (аналогия между TCP и UDP — кто в здравом уме использует для соединений UDP, если нет требований по производительности?). Ты, кстати, сказал, что ты не о скорости. Но если не о скорости, то зачем ты вообще смотришь в сторону НЕ ФИФО? Можешь пояснить. В любом случае тебе никто не мешает рассматривать ФИФО как частный случай произвольного порядка — не используй его гарантии и всё.

Здравствуйте, C0s, Вы писали:

C0s>Здравствуйте, remark, Вы писали:

R>>Кстати, Курилка, и все, кто работает с Эрланг и другими реализациями актёров или обмена сообщениями, как вы относитесь к идеи убрать любые гарантии ФИФО?

C0s>немного не в тему, может быть, но в высокоуровневых системах, построенных на обмене сообщениями, лично я всегда придерживался архитектур с более, чем одним потребителем, висящем на одной очереди (load balancing + failover), что автоматически отменяло возможность выдвигать требования обработки сообщений в порядке их генерации

Но не становится ли у тебя очередь нехилым ботлнеком с тучей (возможно конфликтующих) писателей/читателей?

Здравствуйте, eao197, Вы писали:

E>Про динамическую типизацию я в курсе Подразумевались конструкции вида:
E>

E>receive
E>  { OK, Data } -> ...
E>  { FAILURE, Reason } -> ...
E>  ...
E>

E>Если процесс получил несколько сообщений вида {OK, D}, где D в каждом экземпляре сообщения имеет собственное значение (например, {OK, 2007}, {OK, 2008}, {OK, 2009}), то гарантирует ли Эрланг, что эти сообщения (т.е. {OK, D}) будут извлекаться из хранилища сообщений процесса в ФИФО?

Если это сообщения от одного отправителя — да.
Хотя есть некоторые ньюансы, см. здесь

Здравствуйте, remark, Вы писали:

R>Неупорядоченные сообщения это, может, и кошерно. Но факт в том, что никто такую систему использовать не будет. Если кто-нибудь придёт к пользователям Erlang, Scala Actors, Concurrency and Coordination Runtime и др. и скажет, что давайте ка мы у вас уберём ФИФО, т.к. так более кошерно, то его сразу пинками погонят. Правильно, а зачем им это надо?

можно представить себе такую систему. Есть обрабатывающие потоки и пишущие потоки. У обрабатывающего потока есть своя очередь для каждого пишущего потока, очередь для возврата результатов которые регестрируются при создании системы, и очередь при переполнении очереди на запись. Если у нас чтение неблокирующее и не зависит от записи (версионность), то обрабатывающие потоки выполняют чтение, если есть запись посылают в определенную очередь метод, и продолжают обрабатывать новые методы или возвращаемые из записывающих. В свою очередь записывающие обрабатывают очереди поочередно. Относительно очереди это будет ФИФО, а вот относительно времени поступления запроса, то нет

T>>В Эрланге нет ФИФО, как такового. "Внимательней вглядись" (C) Басё

E>Правильно ли я понимаю, что если в Эрланге процессу пришло несколько однотипных сообщений, то Эрланг не гарантирует их выборку в receive в порядке ФИФО?

Не "пришло", а "послали".

Тогда — да.

Если они уже лежат в очереди процесса, то, по-моему, ФИФО.

E>>Если процесс получил несколько сообщений вида {OK, D}, где D в каждом экземпляре сообщения имеет собственное значение (например, {OK, 2007}, {OK, 2008}, {OK, 2009}), то гарантирует ли Эрланг, что эти сообщения (т.е. {OK, D}) будут извлекаться из хранилища сообщений процесса в ФИФО?

К>Если это сообщения от одного отправителя — да.

Во.

А у нас их несколько, в общем случае.

Так что можно считать, что и нет никакого ФИФО.