Алгоритм Скина — различия между версиями

Материал из Викиконспекты
Перейти к: навигация, поиск
м (rollbackEdits.php mass rollback)
 
(не показаны 2 промежуточные версии 2 участников)
Строка 11: Строка 11:
 
# Инициатор отправляет сообщение и своё время (''предварительное время сообщения'') всем получателям
 
# Инициатор отправляет сообщение и своё время (''предварительное время сообщения'') всем получателям
 
# При приеме сообщения процесс запоминает сообщение со временем в очередь (как нефинализированное) и отправляет свое время инициатору
 
# При приеме сообщения процесс запоминает сообщение со временем в очередь (как нефинализированное) и отправляет свое время инициатору
# Когда инициатору вернулись все подтверждения, он выбирает максимальное время из них и снова отправляет сообщение со финализированным временем
+
# Когда инициатору вернулись все подтверждения, он выбирает максимальное время из них и снова отправляет сообщение с финализированным временем
 
# Получатель может обработать сообщение, если оно помечено как финальное и имеет минимальное время среди всех известных получателю сообщений (и финальных, и нефинальных; иначе может получиться, что финализация сообщений произойдёт в разном порядке у разных получателей и нарушится общий порядок)
 
# Получатель может обработать сообщение, если оно помечено как финальное и имеет минимальное время среди всех известных получателю сообщений (и финальных, и нефинальных; иначе может получиться, что финализация сообщений произойдёт в разном порядке у разных получателей и нарушится общий порядок)
  

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

Алгоритм Скина[1] для организации общего порядка сообщений. Лучше, чем Алгоритм Лампорта, потому что для multicast сообщений общается только с получателями, а не со всеми процессами системы.

Используются логические часы Лампорта. Ниже алгоритм расписан чуть подробнее, чем в Garg и на лекции, но вроде всё ещё верно.

У каждого процесса есть очередь принятых необработанных multicast сообщений. Каждое сообщение имеет временну́ю метку и флаг — финализирована ли метка.

  1. Инициатор отправляет сообщение и своё время (предварительное время сообщения) всем получателям
  2. При приеме сообщения процесс запоминает сообщение со временем в очередь (как нефинализированное) и отправляет свое время инициатору
  3. Когда инициатору вернулись все подтверждения, он выбирает максимальное время из них и снова отправляет сообщение с финализированным временем
  4. Получатель может обработать сообщение, если оно помечено как финальное и имеет минимальное время среди всех известных получателю сообщений (и финальных, и нефинальных; иначе может получиться, что финализация сообщений произойдёт в разном порядке у разных получателей и нарушится общий порядок)

Полный порядок задается финальными временными метками. Финальные метки нужны, чтобы как-то зависеть от времени получателей. Доказательство на лекции и в Gaarg не приводилось.

Итого $3(k-1)$ сообщений на каждый multicast на $k$ процессов (не обсуждалось на лекции, но вроде так).