Алгоритм для синхронного порядка — различия между версиями
Yeputons (обсуждение | вклад) (Новая страница: «Этот алгоритм берёт систему с асинхронным(?) порядком и начинает гарантировать в ней Ие…») |
м (rollbackEdits.php mass rollback) |
||
| (не показаны 4 промежуточные версии 2 участников) | |||
| Строка 1: | Строка 1: | ||
| + | [[Категория: Параллельное программирование]] | ||
Этот алгоритм берёт систему с асинхронным(?) порядком и начинает гарантировать в ней [[Иерархия порядков сообщений#Синхронный порядок|синхронный порядок]]. | Этот алгоритм берёт систему с асинхронным(?) порядком и начинает гарантировать в ней [[Иерархия порядков сообщений#Синхронный порядок|синхронный порядок]]. | ||
| − | Алгоритм для синхронного порядка основан на иерархии процессов. | + | Алгоритм для синхронного порядка основан на иерархии процессов (точнее, произвольном DAG процессов, отправлять сообщения могут только соединённые ребром), мы рассмотрим полный линейный порядок. |
Упорядочим процессы по номеру, назовем сообщение ''большим'', если номер отправителя больше номера получателя, и ''малым'' иначе. | Упорядочим процессы по номеру, назовем сообщение ''большим'', если номер отправителя больше номера получателя, и ''малым'' иначе. | ||
Процесс может быть в ''активном'' или ''пассивном состоянии''. Изначально все активны. | Процесс может быть в ''активном'' или ''пассивном состоянии''. Изначально все активны. | ||
| − | + | В пассивном состоянии процесс не может ни отправлять, ни получать сообщения, он их складывает в очередь и ждёт, пока не станет активным. | |
| + | |||
| + | Если процесс хочет отправить большое сообщение, то он его отправляет и ждёт подтверждения. | ||
| + | А пока ждёт — становится пассивным. | ||
| + | |||
| + | [[Файл:distributed-order-sync-algo-big.png|400px]] | ||
Чтобы отправить сообщение большему процессу <tex>P_j</tex>, процесс <tex>P_i</tex> сначала посылает служебное сообщение, ''запрос''. В ответ <tex>P_j</tex> отправляет ''разрешение''; он может сделать это только в активном состоянии. Разрешив, он становится пассивным и остается в этом состоянии, пока не получает сообщение, которое разрешил. | Чтобы отправить сообщение большему процессу <tex>P_j</tex>, процесс <tex>P_i</tex> сначала посылает служебное сообщение, ''запрос''. В ответ <tex>P_j</tex> отправляет ''разрешение''; он может сделать это только в активном состоянии. Разрешив, он становится пассивным и остается в этом состоянии, пока не получает сообщение, которое разрешил. | ||
| + | |||
| + | [[Файл:distributed-order-sync-algo-small.png|400px]] | ||
| + | |||
| + | Таким образом, сообщения по факту "передаются" только от больших к маленьким и тогда можно нарисовать стрелочки. | ||
| + | Взаимная блокировка наступить не может: мы ждём только меньших процессов, а транзитивность у нас есть и циклов быть не может. | ||
| + | Если маленький хочет отправить сообщение большому, то он отсылает запрос и продолжает работать (посылать большие и маленькие сообщения, менять своё состояние). | ||
| + | Ничего страшного, что по факту сообщение "отправится" только через какое-то время — с точки зрения процесса оно просто долго было в пути. | ||
| + | |||
| + | Разумеется, надо аккуратно доказать, что функцию $T$ можно придумать. Это делается на странице 200 в Gaarg, там происходит что-то вроде логических часов. | ||
| + | |||
| + | Итого на $m$ сообщений нам требуется послать не больше $3m$ сообщений (худший случай — все сообщения маленькие). | ||
Текущая версия на 19:06, 4 сентября 2022
Этот алгоритм берёт систему с асинхронным(?) порядком и начинает гарантировать в ней синхронный порядок.
Алгоритм для синхронного порядка основан на иерархии процессов (точнее, произвольном DAG процессов, отправлять сообщения могут только соединённые ребром), мы рассмотрим полный линейный порядок. Упорядочим процессы по номеру, назовем сообщение большим, если номер отправителя больше номера получателя, и малым иначе. Процесс может быть в активном или пассивном состоянии. Изначально все активны. В пассивном состоянии процесс не может ни отправлять, ни получать сообщения, он их складывает в очередь и ждёт, пока не станет активным.
Если процесс хочет отправить большое сообщение, то он его отправляет и ждёт подтверждения. А пока ждёт — становится пассивным.
Чтобы отправить сообщение большему процессу , процесс сначала посылает служебное сообщение, запрос. В ответ отправляет разрешение; он может сделать это только в активном состоянии. Разрешив, он становится пассивным и остается в этом состоянии, пока не получает сообщение, которое разрешил.
Таким образом, сообщения по факту "передаются" только от больших к маленьким и тогда можно нарисовать стрелочки. Взаимная блокировка наступить не может: мы ждём только меньших процессов, а транзитивность у нас есть и циклов быть не может. Если маленький хочет отправить сообщение большому, то он отсылает запрос и продолжает работать (посылать большие и маленькие сообщения, менять своё состояние). Ничего страшного, что по факту сообщение "отправится" только через какое-то время — с точки зрения процесса оно просто долго было в пути.
Разумеется, надо аккуратно доказать, что функцию $T$ можно придумать. Это делается на странице 200 в Gaarg, там происходит что-то вроде логических часов.
Итого на $m$ сообщений нам требуется послать не больше $3m$ сообщений (худший случай — все сообщения маленькие).
