Почему консенсус-число для теста и набора 2?

17

Согласно Википедии ,

Операция test-and-set может решить проблему консенсуса без ожидания для не более чем двух одновременных процессов.

Почему это не может решить проблему для более чем двух процессов?

Бен
источник

Ответы:

17

Просто чтобы убедиться, что мы находимся на одной странице, сначала давайте рассмотрим эти три определения:

Определение.Test-and-set - это инструкция чтения-изменения-записи в некотором двоичном регистре (скажем, 0 и 1 - возможные значения), где поток получает старое значение и записывает 1.

Определение. Достигнут консенсус между темами, если все nnn потоков принимают решение об одном и том же значении (требование согласованности), а все потоки принимают решение о значении, которое фактически было предложено одним из потоков (требование достоверности).

Defintion.Согласованный протокол не требует ожидания, если каждый вызов метода завершается за конечное число шагов.

Теперь следуйте двум контрольным эскизам.

Утверждение 1. Согласованное количество тестов и наборов составляет не менее 2. Доказательство. Предположим, что у нас есть два потока 0 и 1, которые должны достичь консенсуса. Мы могли бы сделать это, позволив каждому потоку следовать согласованному протоколу ниже:

  1. Запишите предложенное значение в , где t - идентификатор потока, а AA[t]tA - массив размера 2.
  2. Выполните инструкцию проверки и установки для некоторого регистра с помощью RRR инициализированным в 0.
  3. Если возвращаемое значение равно 0, вы были первым: верните . В противном случае вы были вторым: вернуть A [ | т - 1 | ] .A[t]A[|t1|]

Вы можете убедиться, что согласие и ожидание удовлетворены.

(Для следующего доказательства я вложу некоторые доказательства и определения, потому что я думаю, что это будет легче следовать.)

Утверждение 2. Согласованное количество тестов и наборов не более 2. Доказательство. Противоречие Предположим, у нас есть три потока , B и C, которые хотят принять решение о значениях a , b и c соответственно, и что у нас есть некоторый действительный консенсусный протокол без ожидания, который реализован с использованием test-and-set (и атомарного чтения и записи ).ABCabc

Мы можем визуализировать процесс консенсуса в виде ориентированного дерева, где:

  • Корень - это состояние, в котором ни один из потоков не «сделал ход»;
  • Левый потомок узла представляет состояние, которое возникает после перемещения на , средний потомок представляет состояние, которое получается после перемещения на B , а правый дочерний элемент представляет состояние, которое получается после перемещения на CABC ;
  • Конечный узел представляет состояние, в котором все потоки закончили. С конечным узлом связано значение , b или c , где значение зависит от того, какое значение было выбрано для этого конкретного выполнения.abc

Определение. Пусть состояние будет многовалентным, если результат процесса консенсуса еще не определен. Другими словами, не все возможные чередования оставшихся ходов приводят к одному и тому же результату. Пусть состояние будет однолистны , когда исход процесса консенсуса является определен.

Корень многовалентный. Доказательство. Если активен только один поток а другие потоки лежат бездействующими навсегда, то X завершит работу за конечное число шагов (гарантировано предположением о свободе ожидания) и решит x (поскольку он имеет доступ только к этому значению и его решение будет соответствовать требованию консенсуса действительности). Таким образом, для нашей ситуации a , b и c - все возможные результаты. XXxabc

Определение. Пусть критическое состояние будет многовалентным, с дополнительным свойством, что движение определит а , а движение В определит бAaBb .

Существует критическое состояние. Доказательство. Сверху мы знаем, что начинаем в многовалентном состоянии. Пусть вообще не двигается. Пока A или B не приводят дерево в однолистное состояние, пусть оно делает ход. Бесполезность ожидания гарантирует, что дерево конечно, поэтому в какой-то момент критическое состояние должно возникнуть. CAB

Теперь рассмотрим сценарий, в котором мы находимся в критическом состоянии. Есть как минимум две возможности:

1) делает свой ход (тем самым определяя а ) и останавливается. Затем B делает свой ход и останавливается. Следующий C работает до тех пор, пока не закончится, в конечном счете решить .AaBCa

2) делает свой ход (тем самым определяя b ) и останавливается. Следующий C выполняется до его завершения, в конечном итоге решая b . А не делает ход.BbCbA

Поскольку атомарное чтение и запись имеют согласованное число 1, шаги и B должны были быть инструкциями проверки и установки для одного и того же регистра (если регистры различны, то C не сможет определить порядок, в котором A и Б ходы случались). С точки зрения C , сценарии 1 и 2 неразличимы, поэтому мы должны иметь, чтобы C решал и a, и b . Это невозможно. ABCABCCab

То, что инструкция «проверить и установить» имеет консенсус № 2, следует из обоих пунктов 1 и 2.

Рой О.
источник
Спасибо за ответ, Рой. Можете ли вы указать на любой материал по этой теме, который так же ясен, как и ваше объяснение? :). Все материалы, которые я нашел, были слишком формальными.
Санатана
@sanatana: я забыл ответить на твой вопрос, извини. Если это все еще актуально: я предлагаю Херлихи и Шавита «Искусство многопроцессорного программирования» (в частности, главу 5) и материал курса Fokkink по курсу Concurrency & Multithreading: cs.vu.nl/~tcs/cm (который основан на Книга Герлихи и Шавита). Внизу страницы вы найдете ссылку на видео-лекции Херлихи (лекция от 27 сентября о консенсусе). Изучив материал, я понимаю, что для такого рода доказательства достаточно рассмотреть бинарное дерево. Возможно, я обновлю свой ответ позже.
Рой О.
@RoyO. Я вижу, что ваш ответ предполагает, что нет никакого способа достичь консенсуса с 3 процессами. Просто хотел понять, доказали ли мы каким-либо образом, что мы все еще можем прийти к консенсусу, но этот протокол не будет свободен от ожидания?
конечная причина
6

В статье в Википедии есть ссылка, которая отвечает на ваш вопрос, но, возможно, вы не хотите читать этот 26-страничный документ. Я приведу упрощенную версию (довольно технического) доказательства, показывающего, что тестирование и установка не могут решить двоичный консенсус для 3 процессов. Этот тип аргумента широко используется при доказательстве числа консенсуса.

Предположим, у нас есть согласованный алгоритм, использующий регистры TAS для 3 процессов.

В любой момент времени каждый процесс будет иметь ход (инструкцию), готовый к выполнению. Какая из трех инструкций будет выполнена, не является детерминированной.

Предположим, что мы находимся в двухвалентном состоянии (состояние, в котором все еще возможно принятие решения 0 или 1), и какой бы процесс ни шел дальше, последующее состояние будет однолистным. Такое состояние в конечном итоге должно быть достигнуто из-за состояния ожидания.

Предположим (wlg), что если процесс 1 перемещается, состояние будет 0-валентным, а если процесс 2 перемещается, состояние будет 1-валентным. Оба перемещения должны быть операцией TAS (или, по крайней мере, некоторой записью) в одном и том же регистре, поскольку, если бы они были операциями TAS в разных регистрах, мы не могли бы определить, был ли процесс 1 перемещен первым или процесс 2 перемещен первым.

Давайте рассмотрим эти два возможных исполнения:

  • Процесс 1 движется первым, затем процесс 2 движется, затем процесс 3 запускается один
  • Процесс 2 движется первым, затем процесс 3 запускается один

С точки зрения процесса 3 эти состояния неразличимы, поскольку он просто видит значение, записанное процессом 2. Однако в первом случае он должен давать 0 в качестве вывода, а во втором 1 - в качестве вывода. Понятно, что это противоречие.

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

Том ван дер Занден
источник
1

Еще один способ доказать, что тестирование и установка не могут быть использованы для достижения консенсуса с 3 процессорами, - показать, что тестирование и установка могут быть реализованы с использованием консенсуса с 2 процессорами. Тогда допущение, что тест-и-набор может решить консенсус с 3 процессорами, приводит к противоречию: предположим, что тест-и-набор может решить консенсус с 3 процессорами; затем, заменяя test-and-set его реализацией с использованием консенсуса с 2 процессорами, можно получить реализацию консенсуса с 3 процессорами с использованием консенсуса с 2 процессорами, что невозможно. Таким образом, тест-и-набор не может решить консенсус трех процессоров.

Чтобы реализовать тестирование и установку для n-процессоров с использованием консенсуса с 2 процессорами, пусть процессоры определяют победителя теста и наборов с использованием турнира, в котором каждый матч проводится с использованием консенсуса с 2 процессорами (в матче процессоры предложить их идентификатор и результат консенсуса говорит им, кто победит).

нано
источник
0

В практическом смысле может быть достаточно менее строгого консенсусного определения (здесь я называю его легким консенсусом):

Определение . Достигнут легкий консенсус между n потоками, если (a) каждый поток либо принимает одно и то же значение, либо значение для него неизвестно, (b) по крайней мере один поток знает это значение и (c) это значение фактически было предложено одним из темы.

Следовательно, этот консенсус в его более легком смысле допускает, что некоторый поток не знает консенсуса, значение, которое решено.

Следствие : в этом более легком смысле тест-и-набор имеет бесконечное число световых согласований.

Утверждение : это легкое чувство практично. Например, чтобы выбрать поток для входа в критическую секцию, нет необходимости создавать консенсус в строгом смысле. То есть: каждый поток должен знать, был ли он выбран или нет, однако, если он не выбран, ему не нужно будет знать, который был выбран. Другими словами, для взаимного исключения не требуется строгого согласия, достаточно света.

Дьюла Чом
источник