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