Кворум — различия между версиями
Yeputons (обсуждение | вклад) |
|||
| Строка 1: | Строка 1: | ||
[[Категория: Параллельное программирование]] | [[Категория: Параллельное программирование]] | ||
| − | '''Кворум''' - семейство подмножеств множества процессов причем | + | {{Определение |
| + | |definition= | ||
| + | '''Кворум''' - это семейство $Q$ подмножеств множества процессов $2^\mathbb P$ причем: | ||
| + | * $Q$ замкнуто относительно взятия надмножества, т.е. если $Q \ni A \subseteq B$, то $B \in Q$ | ||
| + | * Любые два элемента (т.е подмножества относительно множества процессов) этого семейства имеют непустое пересечение. | ||
| + | }} | ||
| + | Кворум позволяет решить проблему отсутствия взаимного исключения в CS: выбираем кворум $Q$, а дальше каждая вершина должна получить разрешение на вход в критическую секцию у кворума. | ||
| + | Фишка в том, что каждая вершина может выбрать свой собственный кворум. | ||
| + | Например, при оптимизации задержки можно послать запрос всем, а войти в секцию, как только получили подтверждение от хоть какого-нибудь семейства из кворума. | ||
| − | Пример | + | Тонкость: если каждая вершина просто разрешает войти в критическую секцию первому приславшему запрос, |
| − | Рассмотрим 5 процессов | + | то получаем deadlock из-за проблем с порядком сообщений при broadcast (например, если у нас кворум — это два выделенных координатора). |
| + | Так что нам нужно требовать total order multicast, например, [[Алгоритм Скина|алгоритмом Скина]] (дальше в билетах, тут на него просто ссылаемся). | ||
| + | |||
| + | == Пример == | ||
| + | Рассмотрим 5 процессов — P1, P2, P3, P4, P5. | ||
Кворумом для них будет следующее семейство: {[P1, P2, P3], [P3, P4, P5]}. | Кворумом для них будет следующее семейство: {[P1, P2, P3], [P3, P4, P5]}. | ||
Версия 19:36, 2 июня 2019
| Определение: |
Кворум - это семейство $Q$ подмножеств множества процессов $2^\mathbb P$ причем:
|
Кворум позволяет решить проблему отсутствия взаимного исключения в CS: выбираем кворум $Q$, а дальше каждая вершина должна получить разрешение на вход в критическую секцию у кворума. Фишка в том, что каждая вершина может выбрать свой собственный кворум. Например, при оптимизации задержки можно послать запрос всем, а войти в секцию, как только получили подтверждение от хоть какого-нибудь семейства из кворума.
Тонкость: если каждая вершина просто разрешает войти в критическую секцию первому приславшему запрос, то получаем deadlock из-за проблем с порядком сообщений при broadcast (например, если у нас кворум — это два выделенных координатора). Так что нам нужно требовать total order multicast, например, алгоритмом Скина (дальше в билетах, тут на него просто ссылаемся).
Пример
Рассмотрим 5 процессов — P1, P2, P3, P4, P5.
Кворумом для них будет следующее семейство: {[P1, P2, P3], [P3, P4, P5]}.
Кстати, такое семейство тоже будет кворумом: {[P1, P2, P3, P4, P5]}.
Кворум замкнут по надмножеству.
Еще примеры: кворум простого большинства, "рушащаяся" стенка.
