Общий порядок сообщений — различия между версиями

Материал из Викиконспекты
Перейти к: навигация, поиск
м (Yeputons переименовал страницу Total order в Общий порядок сообщений)
м (rollbackEdits.php mass rollback)
 
(не показано 8 промежуточных версий 2 участников)
Строка 1: Строка 1:
 
[[Категория: Параллельное программирование]]
 
[[Категория: Параллельное программирование]]
'''Полный порядок''' - для любых сообщений ''x'' и ''y'' и любых потоков ''P'' и ''Q'' если ''x'' принято в ''P'' перед ''y'', то ''y'' не может быть принято перед ''x'' в ''Q''.
+
В системах, которые отсылают одно сообщение нескольким процессам, могут обнаружиться неприятные спецэффекты даже если не нарушен синхронный порядок:
 +
 
 +
[[Файл:distributed-total-order-wrong.png|400px]]
 +
 
 +
Проблема в том, что в исходной модели нет операции "отправить сообщение нескольким получателям" и на самом деле $P$ и $S$ отправляют два независимых сообщения двум разным процессам.
 +
 
 +
Расширим модель: введём для сообщения вместо обычного события $rcv(m)$ события $rcv_p(m)$ — процесс $p$ получил событие $m$ (определено для всех $p$ для broadcast-сообщений и только для некоторых $p$ в случае multicast/unicast).
 +
{{Определение
 +
|definition=
 +
В системе с broadcast/multicast-сообщениями имеется '''общий порядок''' (total order), если не существует двух сообщений $x$, $y$ и двух потоков $P$, $Q$ таких, что сообщения были приняты в этих потоках в разном порядке: $rcv_P(x) < rcv_P(y) \land rcv_Q(y) < rcv_Q(x)$.
 +
}}
 +
Если у нас только unicast-сообщения, то общий порядок тривиально выполняется даже в асинхронном порядке.
 +
 
 +
В каком-то смысле гарантирование общего порядка для broadcast сообщений похоже на задачу взаимного исключения: отправитель вошёл в критическую секцию, отправил всем остальным сообщение через FIFO-канал, снял критическую секцию. Например, можно решать [[Централизованный алгоритм взаимного исключения|централизованным алгоритмом]].

Текущая версия на 19:04, 4 сентября 2022

В системах, которые отсылают одно сообщение нескольким процессам, могут обнаружиться неприятные спецэффекты даже если не нарушен синхронный порядок:

Distributed-total-order-wrong.png

Проблема в том, что в исходной модели нет операции "отправить сообщение нескольким получателям" и на самом деле $P$ и $S$ отправляют два независимых сообщения двум разным процессам.

Расширим модель: введём для сообщения вместо обычного события $rcv(m)$ события $rcv_p(m)$ — процесс $p$ получил событие $m$ (определено для всех $p$ для broadcast-сообщений и только для некоторых $p$ в случае multicast/unicast).

Определение:
В системе с broadcast/multicast-сообщениями имеется общий порядок (total order), если не существует двух сообщений $x$, $y$ и двух потоков $P$, $Q$ таких, что сообщения были приняты в этих потоках в разном порядке: $rcv_P(x) < rcv_P(y) \land rcv_Q(y) < rcv_Q(x)$.

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

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