Алгоритм Скина — различия между версиями
Yeputons (обсуждение | вклад) |
м (rollbackEdits.php mass rollback) |
||
| (не показаны 4 промежуточные версии 3 участников) | |||
| Строка 5: | Строка 5: | ||
Используются [[Логические часы Лампорта|логические часы Лампорта]]. | Используются [[Логические часы Лампорта|логические часы Лампорта]]. | ||
Ниже алгоритм расписан чуть подробнее, чем в Garg и на лекции, но вроде всё ещё верно. | Ниже алгоритм расписан чуть подробнее, чем в Garg и на лекции, но вроде всё ещё верно. | ||
| + | |||
| + | У каждого процесса есть очередь принятых необработанных multicast сообщений. | ||
| + | Каждое сообщение имеет временну́ю метку и флаг — финализирована ли метка. | ||
| + | |||
# Инициатор отправляет сообщение и своё время (''предварительное время сообщения'') всем получателям | # Инициатор отправляет сообщение и своё время (''предварительное время сообщения'') всем получателям | ||
| − | # При приеме сообщения процесс запоминает сообщение со | + | # При приеме сообщения процесс запоминает сообщение со временем в очередь (как нефинализированное) и отправляет свое время инициатору |
| − | # Когда инициатору вернулись все | + | # Когда инициатору вернулись все подтверждения, он выбирает максимальное время из них и снова отправляет сообщение с финализированным временем |
| − | # Получатель | + | # Получатель может обработать сообщение, если оно помечено как финальное и имеет минимальное время среди всех известных получателю сообщений (и финальных, и нефинальных; иначе может получиться, что финализация сообщений произойдёт в разном порядке у разных получателей и нарушится общий порядок) |
Полный порядок задается финальными временными метками. Финальные метки нужны, чтобы как-то зависеть от времени получателей. | Полный порядок задается финальными временными метками. Финальные метки нужны, чтобы как-то зависеть от времени получателей. | ||
Доказательство на лекции и в Gaarg не приводилось. | Доказательство на лекции и в Gaarg не приводилось. | ||
| + | |||
| + | Итого $3(k-1)$ сообщений на каждый multicast на $k$ процессов (не обсуждалось на лекции, но вроде так). | ||
Текущая версия на 19:37, 4 сентября 2022
Алгоритм Скина[1] для организации общего порядка сообщений. Лучше, чем Алгоритм Лампорта, потому что для multicast сообщений общается только с получателями, а не со всеми процессами системы.
Используются логические часы Лампорта. Ниже алгоритм расписан чуть подробнее, чем в Garg и на лекции, но вроде всё ещё верно.
У каждого процесса есть очередь принятых необработанных multicast сообщений. Каждое сообщение имеет временну́ю метку и флаг — финализирована ли метка.
- Инициатор отправляет сообщение и своё время (предварительное время сообщения) всем получателям
- При приеме сообщения процесс запоминает сообщение со временем в очередь (как нефинализированное) и отправляет свое время инициатору
- Когда инициатору вернулись все подтверждения, он выбирает максимальное время из них и снова отправляет сообщение с финализированным временем
- Получатель может обработать сообщение, если оно помечено как финальное и имеет минимальное время среди всех известных получателю сообщений (и финальных, и нефинальных; иначе может получиться, что финализация сообщений произойдёт в разном порядке у разных получателей и нарушится общий порядок)
Полный порядок задается финальными временными метками. Финальные метки нужны, чтобы как-то зависеть от времени получателей. Доказательство на лекции и в Gaarg не приводилось.
Итого $3(k-1)$ сообщений на каждый multicast на $k$ процессов (не обсуждалось на лекции, но вроде так).