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

E>>Понятно, просто я в C++ных примерах использования future никогда не видел continueWith.

AVK>Интересно, ты вообще мое исходное сообщение читал?

Исходное -- это какое? Там где ты написал, что я не понимаю, что такое фьючерс?

AVK> Я ведь именно об этом и писал.

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

E>>А каким боком Cilk к модели обмена сообщениями относится?

AVK>Это пример одной из методик балансинга — work stealing.

Только в Cilk-е выполняется "кража" фрагментов стека. А в модели агентов будет просто другой подход.

AVK>Ее же можно для агентов применять, если мы агентов используем для распараллеливания вычислений.

Ее можно применять, например, и так: у какого-то агента есть очередь с N уже помещенных туда сообщений. При наличии свободных процессов сообщения из этой очереди могут извлекаться свободными процессорами и обрабатываться. При вычислениях, не завязанных на состояние, это будет нормально работать.

А если операция завязана на состояние, то даже в Clik-е для этого применяется специальная конструкция inlet, которая сильно сокращает возможности work stealing-а (по крайней мере так я понял из Wikipedia).

AVK>Ты ведь еще исходную тему топика, надеюсь, не забыл?

Я думал, мы здесь сейчас обсуждаем вопрос remark-а к пользователям различных систем на обмене сообщений о необходимости сохранения ФИФО вообще.

AVK>Все это решаемо, возможно просто придется редуцировать набор предикатов до небольшого количества стандартных случаев.

Тогда ты предлагаешь не универсальное, а частное и весьма ограниченное решение.

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

S>Пусть отправитель шлет sendWriteDataWithParams(params, data).
S>А получатель самостоятельно делает resetDevice.

Это не всегда возможно. Так же, как не всегда известно на момент отправки setParams, какие данные затем будут записаны. Так же, как не всегда при отсылке данных известно, какие параметры нужно передавать устройству.

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

E>>Можно еще одну ситуацию вспомнить. Допустим, у нас есть агенты s и r. Они работают на узлах A и B (имеются в виду узлы локальной сети). Но эти узлы соеденены не напрямую, а через несколько других узлов. И путь от A к B может лежать через маршрут A -> D -> E -> B или через маршут A -> C -> B. Агент s с узла A отправляет сообщения m1, m2, m3. Сообщения m1 и m3 уходят по маршруту A->D->E->B, а сообщение m2 -- по маршруту A->C->B. В этом случае сообщения r может получить как m2, m1, m3, так и m1, m3, m2, так и m1, m2, m3. Если логика взаимодействия s и r построена на гарантиях ФИФО для сообщений от одного источника, то все накрывается медным тазом.
S>Вот мне в этом плане вот что интересно: протокол IP как раз описывает ровно эту ситуацию.
S>И есть традиционное решение для построения на нём FIFO порядка, которое не требует никакой синхронизации "в середине", широко известное под аббревиатурой TCP.

Аналогия между TCP и передачей сообщений некорректна. В TCP данные передаются потоком и любой новый пакет автоматически объявляется шествующим за предыдущим пакетом. Поэтому параметры упорядочения присутствуют в каждом из пакетов и позволяют производить их пересборку на стороне получателя.

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

Сделать так, чтобы транспортный протокол, используемый для передачи сообщений, поддерживал дисциплину ФИФО можно (для случая signle-producer->single-consumer и single-node-producers->single-consumer). И, если разработчик нуждается в подобной дисциплине, он должен проверить, поддерживает ли ее используемый им инструмент.

Здравствуйте, eao197, Вы писали:
E>Это не всегда возможно. Так же, как не всегда известно на момент отправки setParams, какие данные затем будут записаны. Так же, как не всегда при отсылке данных известно, какие параметры нужно передавать устройству.
На мой взгляд, это очень странно. Ты только что написал пример. Даже если между строчками происходит масса всякой вредной деятельности, мне очень странно, что к моменту отправки writeData отправитель уже забыл, что за параметры он отправлял в прошлый раз. Если между ними нет зависимости, то и порядок прихода будет неважен. А если есть, то потерять их можно только специально. Я не вижу никакой нужды в этом.

Это примерно то же самое, что удаленная CУБД по сравнению с файловой системой. То есть клиент начинает слишком сильно заморачиваться передачей низкоуровневых деталей серверу. Это вредно, т.к. создает лишний трафик, а в нашем случае еще и порождает вопросы синхронизации.
Простой пример: протокол DNS не использует идеологии "удаленного чтения файла зоны". Он полностью асинхронный, и всё прекрасно работает, несмотря на отсутствие какого-либо FIFO.

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

E>Аналогия между TCP и передачей сообщений некорректна. В TCP данные передаются потоком и любой новый пакет автоматически объявляется шествующим за предыдущим пакетом. Поэтому параметры упорядочения присутствуют в каждом из пакетов и позволяют производить их пересборку на стороне получателя.
Полностью корректна. Еще раз: если отправителю/получателю важно, в каком порядке приходят сообшения, он просто добавляет в сообщения seq number.
Другого способа нет — разве что неявно всовывать LSN принудительно во все сообщения, но я не вижу в этом никакого смысла.

E>В случае отсылки сообщений, если в сообщениях не заданы эти параметры предшествования/упорядочения самим разработчиком, информации для восстановления порядка отсылки сообщений нет. Можешь увидеть это на примере SMTP -- если ты отправляешь одному и тому же получателю несколько писем, то они могут придти к получателю в разном порядке (особенно, если сообщения сильно различаются по размеру).
И, заметь, никакой проблемы это не представляет.
Если получатель хочет упорядочить по порядку отправки — нет проблем, в каждом письме есть хидер sent timestamp.
Опять же, если мне важно, чтобы ты читал письма в определенном порядке, то я включу эту информацию в письмо.

Еще раз намекаю, что с моей точки зрения, не стоит запихивать поддержку FIFO прямо в самый-самый нижний слой системы. Достаточно сделать удобные библиотеки, позволяющие описывать протокол взаимодействия.

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

S>На мой взгляд, это очень странно. Ты только что написал пример. Даже если между строчками происходит масса всякой вредной деятельности, мне очень странно, что к моменту отправки writeData отправитель уже забыл, что за параметры он отправлял в прошлый раз. Если между ними нет зависимости, то и порядок прихода будет неважен. А если есть, то потерять их можно только специально. Я не вижу никакой нужды в этом.

Вот вполне реальный сценарий. Есть железяка, которая подключена к выделенному узлу сети. На этом узле работает часть софта, отвечающая только за взаимодействия с железякой. Есть другой узел, на котором работает основной софт. Этот основной софт взаимодействует с выделенным узлом и, следовательно, с железякой, посредством обмена сообщениями.

В какой-то момент времени основной софт обнаруживает, что от железяки слишком долго не было никакой информации (такое бывает -- сама железяка подает признаки жизни и обмены с ней проходят корректно, но ничего полезного не происходит (некоторые GSM-модемы временами так "теряют" сеть)). И отправляет команду reset_device -- в 99.9% процентах случаев это помогает. Затем основному софту приходит команда reconfigure с новыми параметрами. Эта команда в конце-концов приводит к отсылке set_params на железяку. После чего основной софт может получить потребность в отправке каких-то данных на железяку -- это делается посредством write_data.

В таком случае нет необходимости заменять write_data на сообщение set_params_and_write_data.

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

E>>Аналогия между TCP и передачей сообщений некорректна. В TCP данные передаются потоком и любой новый пакет автоматически объявляется шествующим за предыдущим пакетом. Поэтому параметры упорядочения присутствуют в каждом из пакетов и позволяют производить их пересборку на стороне получателя.
S>Полностью корректна. Еще раз: если отправителю/получателю важно, в каком порядке приходят сообшения, он просто добавляет в сообщения seq number.

Ну вставят они этот seq_number и что? Получит получатель сначала сообщение с номером 1, а затем с номером 8. И что он должен делать с этим сообщением? Ждать сообщений с номерами 2-7? Или обработать сообщение с номером 8, а затем проигнорировать сообщения с меньшими seq_number-ами?

Имхо, гораздо меньше проблем будет у разработчика, если он знает, что его транспорт обеспечивает FIFO. Тогда не нужно будет нагружать сообщения разными порядковыми номерами и пр.

S>Еще раз намекаю, что с моей точки зрения, не стоит запихивать поддержку FIFO прямо в самый-самый нижний слой системы. Достаточно сделать удобные библиотеки, позволяющие описывать протокол взаимодействия.

Я вообще потерял нить разговора. Про FIFO я здесь пока говорил только применительно к извлечению уже полученных сообщений из очереди агента/процесса. Т.е. если в очередь к агенту уже встали равноприоритетные сообщения m1, m2, m3, то и извлекаться они должны имено в этом порядке. Даже с использованием selective receive, как в Эрланге -- сначала рассматривается m1, затем m2, затем m3. Если было извлечено m2, то следующий receive будет рассматривать m1, затем m3.

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

Здравствуйте, eao197, Вы писали:
E>Ну вставят они этот seq_number и что? Получит получатель сначала сообщение с номером 1, а затем с номером 8. И что он должен делать с этим сообщением? Ждать сообщений с номерами 2-7?
Конечно. Восьмое складывается во внутренний список и откладывается до момента прихода недостающих. Я же сказал — всё как в TCP.

E>Имхо, гораздо меньше проблем будет у разработчика, если он знает, что его транспорт обеспечивает FIFO. Тогда не нужно будет нагружать сообщения разными порядковыми номерами и пр.
Всё как раз наоборот: если разработчик "знает", значит номерами их нагрузил транспорт. Только транспорт нагрузил все сообщения, а не только те, где важен порядок.
С моей точки зрения, это — преждевременная пессимизация.

E>Я вообще потерял нить разговора. Про FIFO я здесь пока говорил только применительно к извлечению уже полученных сообщений из очереди агента/процесса. Т.е. если в очередь к агенту уже встали равноприоритетные сообщения m1, m2, m3, то и извлекаться они должны имено в этом порядке.
Непонятно, что значит "встали". Если это сообшения от разных отправителей, у которых нет скоординированного источника времени, то говорить об их порядке — бессмысленно. Ну вот тебе неожиданный пример: есть SQL. В нём нет никакого "естественного порядка записей". Если хочешь их упорядочить — сделай order by. Если хочешь сортировать по "порядку вставки" — придется делать поле "номер по порядку вставки". Но сам сервер за тебя это не обеспечивает. Ибо нефиг.

E>И я не вижу смысла в том, чтобы на стороне получателя уже находящиеся в его очереди сообщения извлекались не в FIFO порядке. К библиотекам, описывающим протокол взаимодействия это вообще практически не имеет отношения.
Видишь ли, я не хочу оперировать терминами навроде "уже находящиеся". С моей точки зрения, очередь — это в первую голову некий интерфейс.
А каков механизм хранения примитивов — дело десятое. Физически входящая очередь может состоять из набора очередей, каждая из которых посвящена одному отправителю. Благодаря этому можно обойтись без излишней синхронизации, т.к. два отправителя могут помещать туда сообщения, никак не договариваясь друг с другом.

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

E>>Ну вставят они этот seq_number и что? Получит получатель сначала сообщение с номером 1, а затем с номером 8. И что он должен делать с этим сообщением? Ждать сообщений с номерами 2-7?
S>Конечно. Восьмое складывается во внутренний список и откладывается до момента прихода недостающих. Я же сказал — всё как в TCP.

Ну и так отсекается целый ряд задач, где выгоднее просто выбрасывать выбившиеся из своего порядка сообщения. Например, при отображении progress-bar-а, при потоковом вещании, при on-line мониторинге и пр.

E>>Имхо, гораздо меньше проблем будет у разработчика, если он знает, что его транспорт обеспечивает FIFO. Тогда не нужно будет нагружать сообщения разными порядковыми номерами и пр.
S>Всё как раз наоборот: если разработчик "знает", значит номерами их нагрузил транспорт. Только транспорт нагрузил все сообщения, а не только те, где важен порядок.

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

S>С моей точки зрения, это — преждевременная пессимизация.

Может быть.

E>>Я вообще потерял нить разговора. Про FIFO я здесь пока говорил только применительно к извлечению уже полученных сообщений из очереди агента/процесса. Т.е. если в очередь к агенту уже встали равноприоритетные сообщения m1, m2, m3, то и извлекаться они должны имено в этом порядке.
S>Непонятно, что значит "встали". Если это сообшения от разных отправителей, у которых нет скоординированного источника времени, то говорить об их порядке — бессмысленно.

"Встали" -- это значит оказались в хранилище сообщений из которых они забираются затем методом receive (или аналогичным ему).

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

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

Здравствуйте, eao197, Вы писали:
E>В какой-то момент времени основной софт обнаруживает, что от железяки слишком долго не было никакой информации (такое бывает -- сама железяка подает признаки жизни и обмены с ней проходят корректно, но ничего полезного не происходит (некоторые GSM-модемы временами так "теряют" сеть)).
Не очень понятно, почему это обнаруживает не "локальная" часть софта, а какой-то "посторонний" узел сети.
E>И отправляет команду reset_device -- в 99.9% процентах случаев это помогает. Затем основному софту приходит команда reconfigure с новыми параметрами. Эта команда в конце-концов приводит к отсылке set_params на железяку.
Это два совершенно разных события. Почему ты думаешь, что порядок их получения важен?

E>После чего основной софт может получить потребность в отправке каких-то данных на железяку -- это делается посредством write_data.
E>В таком случае нет необходимости заменять write_data на сообщение set_params_and_write_data.
Совершенно верно. Ты привел пример независимых сообщений. Для них порядок не нужен.

Если порядок всё же важен, то сообщения можно объединить. Если имеет смысл структурное объединение, то можно просто склеить сообшения.
Пример: не имеет смысла делать reset_device в одиночку, потому что после него параметры приходят в неопределенное состояние. Значит, надо сразу делать ResetWirhParams.
Пример 2: нам не всё равно, с какими параметрами передавать данные. Значит, надо делать WriteDataWithParams.

Пример 3: накладные расходы на параметры в каждом пакете слишком велики, и мы хотим воспользоваться statefullness принимающего агента (что, конечно же, вредно, но если очень хочется, то рюмочку можно). Ок, тогда мы вводим в протокол порядок сообщений.

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

E>>В какой-то момент времени основной софт обнаруживает, что от железяки слишком долго не было никакой информации (такое бывает -- сама железяка подает признаки жизни и обмены с ней проходят корректно, но ничего полезного не происходит (некоторые GSM-модемы временами так "теряют" сеть)).
S>Не очень понятно, почему это обнаруживает не "локальная" часть софта, а какой-то "посторонний" узел сети.

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

E>>И отправляет команду reset_device -- в 99.9% процентах случаев это помогает. Затем основному софту приходит команда reconfigure с новыми параметрами. Эта команда в конце-концов приводит к отсылке set_params на железяку.
S>Это два совершенно разных события. Почему ты думаешь, что порядок их получения важен?

Потому что для отправителя факт reset_device предшествует факту set_params.

E>>После чего основной софт может получить потребность в отправке каких-то данных на железяку -- это делается посредством write_data.
E>>В таком случае нет необходимости заменять write_data на сообщение set_params_and_write_data.
S>Совершенно верно. Ты привел пример независимых сообщений. Для них порядок не нужен.

Ну да. Начальник пишет подчиненному по e-mail: "Со стороны заказчика с нами теперь будет взаимодействовать не Иванов Иван Иванович, а Сидоров Сидор Сидорыч, его контактная информация вот такая: ...". Через какое-то время начальник дает подчиненному задание по e-mail: "Проинформируй заказчика о том, что нам потребуется увеличение финансирования по этапу X на Y процентов". Можно ли считать эти e-mail-ы независимыми, для которых порядок не нужен? Какова вероятность того, что начальник будет нумеровать подобные письма для подчиненного?

S>Пример: не имеет смысла делать reset_device в одиночку, потому что после него параметры приходят в неопределенное состояние. Значит, надо сразу делать ResetWithParams.

Тогда нет смысла в прикладном сообщении reset_device без параметров. Это означает, что в reset_device параметры будут. И так же это значит, что управляющему агенту придется хранить у себя параметры устройства постоянно, чтобы иметь их под рукой при необходимости отослать reset_device.

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


E>Потому, что локальная часть софта может не видеть всей картины в целом. Если устройство нормально отвечает и присылает какие-то пакеты, то для локальной части устройсво выглядит нормально. А для всей системы может быть очевидно, что устройство не выдает "значимой" информации в течении долгого времени.
Ок, принято.

E>Ну да. Начальник пишет подчиненному по e-mail: "Со стороны заказчика с нами теперь будет взаимодействовать не Иванов Иван Иванович, а Сидоров Сидор Сидорыч, его контактная информация вот такая: ...". Через какое-то время начальник дает подчиненному задание по e-mail: "Проинформируй заказчика о том, что нам потребуется увеличение финансирования по этапу X на Y процентов". Можно ли считать эти e-mail-ы независимыми, для которых порядок не нужен?
E>Какова вероятность того, что начальник будет нумеровать подобные письма для подчиненного?
Если начальник — педант, то будет.
Но пойми, мы же говорим не об абстрактном "жонглировании сообщениями". Речь идет о некотором протоколе. Который и определяет, порядок каких сообщений важен, а каких — неважен. Этот протокол обязаны соблюдать и отправитель, и получатель. Получатель просто будет игнорировать нарушения протокола и всё.

В примере, который ты привел, нет никакой гарантии, что порядок сообщений важен. К примеру, мне до сих пор приходят письма по вопросам, связанным с моей деятельностью две должности назад. Это означает, что отправителю не пришло письмо от его начальника "Теперь с нами будет взаимодействовать не Антон, а Сергей"
Ничего страшного не происходит — я перенаправляю письма Сергею.
Если бы это было страшно, то начальник отправителя позаботился бы о том, чтобы все сообщения были упорядочены.

E>Тогда нет смысла в прикладном сообщении reset_device без параметров. Это означает, что в reset_device параметры будут.
Правильно! Вот видишь — ты всё понимаешь.
E>И так же это значит, что управляющему агенту придется хранить у себя параметры устройства постоянно, чтобы иметь их под рукой при необходимости отослать reset_device.
Совершенно верно — если ему важны параметры, он обязан их предоставлять. Если не важны — то ему не страшно, если параметры будут сброшены.

Здравствуйте, eao197, Вы писали:
E>Ну и так отсекается целый ряд задач, где выгоднее просто выбрасывать выбившиеся из своего порядка сообщения. Например, при отображении progress-bar-а, при потоковом вещании, при on-line мониторинге и пр.

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

E>Поскольку разработчик сам не занимается номерами, то ему без разницы, как порядок обеспечивает транспорт.
Я сейчас говорю о том, чтобы не заниматься предоставлением дорогостоящих гарантий до того, как их закажет разработчик.

E>Да ради бога. Только ты можешь сказать, какой смысл в том, чтобы сообщения от одного отправителя извлекались из этих очередей не в том порядке, в котором они туда встали?
Ты опять про "туда встали"? Это интимная подробность функционирования очереди. В случае одного отправителя можно говорить про очередность отправки. А смысл извлекать в другом порядке простой — благодаря отсутствию зависимостей, инфраструктура может оптимизировать передачу сообщений. К примеру, оба сообщения могут передаваться одновременно по двум независимым шинам, вместо того, чтобы дожидаться друг друга. И receive не будет тратить время на упорядочивание сообщений, порядок которых неважен. Зачем? Мы же стремимся к максимизации быстродействия, а ее главный лозунг — "если можешь — не делай!".

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

E>>Какова вероятность того, что начальник будет нумеровать подобные письма для подчиненного?
S>Если начальник — педант, то будет.

Ну вот в том-то и дело, что начинаются требования к участникам взаимодействия. В тоже время, хочется, чтобы при использовании механизма обмена сообщениями этих требований было как можно меньше. Ну тут как с со сборкой мусора в языке программирования -- ее наличие делает решение целого ряда задач гораздо более простой, надежной и, временами, более производительной. FIFO по умолчанию для single-producer->single-consumer, как мне кажется, является как раз удобным способом для решения задач на основе обмена сообщениями с минимальными требованиями к участникам взаимодействия.

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

S>Нет, ничего не отсекается. Я же не предлагаю захардкодить поддержку FIFO в платформу — это ваша с ремарком позиция.
S>Я как раз наоборот — предлагаю разработчику самостоятельно определять политику упорядочивания сообщений. Например, с помощью библиотек.

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

S>В частности, может быть FIFO, может быть LastOneRules или другие произвольные трактовки.

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

Что мне хочется иметь, так это то, что если агентам S и R требуется FIFO, то они бы заказали это у своей библиотеки и она бы им эту политику предоставила. И чтобы агентам S и R не приходилось заморачиваться на выставление меток времени в своих сообщениях -- это вполне может быть сделано на низком уровне. Т.е. требования FIFO не должны сказываться на структуре сообщений, которыми обмениваются S и R.

E>>Да ради бога. Только ты можешь сказать, какой смысл в том, чтобы сообщения от одного отправителя извлекались из этих очередей не в том порядке, в котором они туда встали?
S> Ты опять про "туда встали"? Это интимная подробность функционирования очереди.

Вероятно, это связано с тем, что мне эти интимные подробности приходится реализовывать.

S> В случае одного отправителя можно говорить про очередность отправки. А смысл извлекать в другом порядке простой — благодаря отсутствию зависимостей, инфраструктура может оптимизировать передачу сообщений. К примеру, оба сообщения могут передаваться одновременно по двум независимым шинам, вместо того, чтобы дожидаться друг друга. И receive не будет тратить время на упорядочивание сообщений, порядок которых неважен.

Понятно.

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

Мне все это сильно напоминает комовские аппартаменты

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

E>Опять не понимаю, о чем мы спорим

E>То, что политики могут быть разными -- это очевидно. И если используемая библиотека обмена сообщениями может поддерживать их несколько, да еще одновременно, так это вообще замечательно.
Значит — разногласий нет. Это замечательно.

E>Что мне хочется иметь, так это то, что если агентам S и R требуется FIFO, то они бы заказали это у своей библиотеки и она бы им эту политику предоставила. И чтобы агентам S и R не приходилось заморачиваться на выставление меток времени в своих сообщениях -- это вполне может быть сделано на низком уровне. Т.е. требования FIFO не должны сказываться на структуре сообщений, которыми обмениваются S и R.
С этим я не спорю. Вопрос, в общем-то, в том, кто и как будет определять протокол. И как потом им пользоваться.

Некоторые разработки на эту тему были, насколько я помню, внедрены в MS SQL Server ажно 2005.

E>Вероятно, это связано с тем, что мне эти интимные подробности приходится реализовывать.
Ок.

Здравствуйте, eao197, Вы писали:
E>Ну вот в том-то и дело, что начинаются требования к участникам взаимодействия. В тоже время, хочется, чтобы при использовании механизма обмена сообщениями этих требований было как можно меньше. Ну тут как с со сборкой мусора в языке программирования -- ее наличие делает решение целого ряда задач гораздо более простой, надежной и, временами, более производительной. FIFO по умолчанию для single-producer->single-consumer, как мне кажется, является как раз удобным способом для решения задач на основе обмена сообщениями с минимальными требованиями к участникам взаимодействия.
В принципе, похоже что да. По крайней мере, обеспечение FIFO в таком случае должно гарантироваться каким-то нетрудоёмким способом.
Тот пример с ручной нумерацией сообщений, который я привел, конечно же неработоспособен. Должно быть что=то более простое.
А вот FIFO для общего случая хитрой топологии может оказаться overkill. А может и нет.

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

S>В принципе, похоже что да. По крайней мере, обеспечение FIFO в таком случае должно гарантироваться каким-то нетрудоёмким способом.
S>Тот пример с ручной нумерацией сообщений, который я привел, конечно же неработоспособен. Должно быть что=то более простое.
S>А вот FIFO для общего случая хитрой топологии может оказаться overkill. А может и нет.

Ну здесь я более-менее четко могу говорить только о своих разработках и своем опыте программирования агентов и с помощью агентов. Так вот, если агенты взаимодействуют друг с другом в рамках одного процесса, то обеспечение FIFO, тривиально, если у агента-получается очередь принятых сообщений одна. Здесь получается как с логированием: в двух нитях для одного объекта-логгера вызывается метод info(), а уже в каком порядке сообщения лягут в log-файл, это уж как нити лягут . Но важно то, что если одна и та же нить последовательно вызвает info() для объекта логгера, то ее записи не перепутаются.

Если агенты работают в разных рантаймах, соединенных одним прямым потоковым каналом (тем же TCP/IP), то и здесь проблем нет.

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

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

E>>Выше речь шла о равноприоритетных сообщениях.

T>Понятно.

T>Я смотрю на всё это с точки зрения динамического потока данных.

T>В этом случае особой важности в ФИФО нет. Но там и состояния. как такового, тоже нет.


А ну тогда понятно, почему тебе не важен порядок и почему ты решил задачу для посылки сообщений в общем случае
Датафлоу, или то, что в программном мире называется task-based parallelism, не требует никакого порядка, в смысле, что термин порядок вообще для него не релевантен, элементы работы (задачи) выполняются как только для них готовы аргументы. Да и вообще, сама пересылка сообщений тут тоже не релевантна, т.к. нет отдельных данных (агентов), соотв. у них нет местоположения, соотв. и посылать даже некуда.
Редукция модели актёров до датафлоу (task-based) следующая: актёр за свою жизнь получает одно и только одно сообщение, соотв. актёр совмещён с этим своим сообщением. Упорядочивания нет, т.к. среди одного сообщения нет порядка, и в то же время на одно сообщение можно наложить любой порядок. Посылок сообщений нет — актёр шедулится либо там где он создаётся, если все данные уже есть в это время; либо тогда и там же когда/где готов последний аргумент.