Re[65]: пример eao197: "сообщения" рвут "разделяемую память"
От: remark Россия http://www.1024cores.net/
Дата: 17.12.08 17:44
Оценка: 21 (1) +1
Здравствуйте, C0s, Вы писали:

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

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

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

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

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



1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.