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

Материал из Викиконспекты
Перейти к: навигация, поиск
м (переименовал «Алгоритм Скрина» в «Алгоритм Скина»: неправильное название алгоритма)
м (rollbackEdits.php mass rollback)
 
(не показано 7 промежуточных версий 5 участников)
Строка 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 сообщений. Каждое сообщение имеет временну́ю метку и флаг — финализирована ли метка.

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

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

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