Чому дорівнює кількість консенсусу для тестування та встановлення 2?


17

За даними Вікіпедії ,

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

Чому він не може вирішити проблему більше двох процесів?

Відповіді:


17

Щоб переконатися, що ми знаходимось на одній сторінці, спочатку розглянемо ці три визначення:

Визначення. Test-and-set - це інструкція для читання-зміни-запису в якомусь двійковому регістрі (скажімо лише, що 0 і 1 - можливі значення), де потік отримує старе значення і пише 1.

Визначення. Консенсус досягається між потоками, якщо всі n потоків визначають однакове значення (вимога узгодженості), а всі потоки визначають значення, яке було фактично запропоновано одним із потоків (вимога дійсності).nn

Визначення. Протокол консенсусу - це не очікування, якщо кожен виклик методу закінчується у визначеній кількості кроків.

Тепер дотримуйтесь двох ескізів.

Заява 1. Кількість консенсусу тесту та встановлення становить не менше 2. Доказ. Припустимо, у нас є дві нитки 0 і 1, які потребують досягнення консенсусу. Ми могли б зробити це, дозволивши кожному потоку слідувати протоколу консенсусу нижче:

  1. Запишіть запропоноване значення в , де t - ідентифікатор потоку, а A - масив розміром 2.A[t]tA
  2. Виконайте інструкцію тестування та встановлення на деякому регістрі , з R, ініційованим на 0.RR
  3. Якщо значення повернення дорівнює 0, ви були першими: поверніть . Інакше ви були другими: поверніть A [ | t - 1 | ] .A[t]A[|t1|]

Ви можете переконатися в тому, що консенсус та безперебійне задоволення задоволені.

(Для наступного доказу я вкладу деякі докази та визначення, тому що я думаю, що це полегшить наслідування.)

Заява 2. Консенсусна кількість тестування та встановлення становить не більше 2. Доказ. За протиріччя. Припустимо, у нас є три потоки , B і C, які бажають визначити значення a , b і c відповідно, і що у нас є дійсний протокол консенсусу без очікування, який реалізується за допомогою тесту і встановлення (і атомний читає і записує ).ABCabc

Ми можемо уявити процес консенсусу як спрямоване дерево, де:

  • Корінь - це стан, коли жодна з ниток не зробила крок;
  • Лівий дочірній вузол представляє стан, який виникає після переміщення по , середній дочірній представляє стан, що виникає після переміщення по В , а правий дитина представляє стан, що виникає після переміщення на С ;ABС
  • Листовий вузол представляє стан, у якому всі нитки закінчені. Пов’язане з вузлом аркуша - це значення , b або c , де значення залежить від того, яке значення було прийнято для конкретного виконання.абc

Визначення. Нехай держава буде багатовалентною, якщо результат консенсусу ще не визначений. Іншими словами, не всі можливі переплетення решти кроків призводять до однакового результату. Нехай стан буде однолістних , коли результат процесу консенсусу буде визначено.

Корінь багатовалентний. Доказ. Якщо тільки один потік активний, а інші потоки лежать спокійно назавжди, тоді X закінчиться в кінцевій кількості кроків (гарантується припущенням про вільність очікування), і він вирішить x (оскільки він має лише доступ до цього значення та його рішення задовольнить вимогу обґрунтованості консенсусу). Отже, для нашої ситуації, a , b і c - всі можливі результати. ХХхабc

Визначення. Нехай критичним станом є стан, який є багатовалентним, з додатковою властивістю, яку хід визначатиме a , а хід B визначає b .АаБб

Існує критичний стан. Доказ. Зверху ми знаємо, що ми починаємо у багатовалентному стані. Нехай взагалі не рухається. Поки або А, або В не змусять дерево в одновалентному стані, нехай він рухається. Вільність очікування гарантує, що дерево є кінцевим, тому в певний момент необхідно зіткнутися з критичним станом. САБ

Тепер розглянемо сценарій, коли ми перебуваємо в критичному стані. Є щонайменше дві можливості:

1) робить свій хід (тим самим визначаючи а ) і зупиняється. Потім B робить свій рух і зупиняється. Далі C працює, поки не закінчиться, врешті-решт вирішивши a .АаБСа

2) робить свій хід (тим самим визначаючи b ) і зупиняється. Далі C працює, поки не закінчиться, врешті-решт, вирішивши b . А не робить ходу.БбСбА

Оскільки атомні читання та записи мають консенсус № 1, кроки і B повинні були бути тестовими та встановленими інструкціями в одному реєстрі (якщо регістри різні, то C не зможе визначити порядок, у якому A і B Рухи Б відбулися). З точки зору C , тоді сценарії 1 і 2 не відрізняються, тому ми повинні мати, що C вирішує і a, і b . Це неможливо. АБСАБССаб

Те, що інструкція про тестування та встановлення має консенсус № 2, випливає з п. 1 і 2.


Дякую за відповідь Рой. Чи можете ви вказати на будь-який матеріал на цю тему, який є таким же чітким, як ваше пояснення? :). Весь знайдений нами матеріал був занадто формальним.
санатана

@sanatana: Я забув відповісти на ваше запитання, вибачте. Якщо це все-таки актуально: я пропоную "Мистецтво багатопроцесорного програмування" Герліхія і Шавіта ( зокрема, глава 5) та навчальний матеріал курсу "Конкурс і багатопоточність" від Fokkink: cs.vu.nl/~tcs/cm (на основі якого Книга Герліхія і Шавіта). Внизу сторінки ви знайдете посилання на відео лекції Герліхія (лекція 27 вересня про консенсус). Переглянувши матеріал, я зрозумів, що достатньо розглянути бінарне дерево для такого роду доказів. Можливо, свою відповідь я оновлю пізніше.
Рой О.

@RoyO. Я бачу, що ваша відповідь говорить про те, що немає можливості дійти до консенсусу з трьома процесами. Просто хотілося зрозуміти, чи якимось чином ми довели, що ми все-таки можемо досягти консенсусу, але цей протокол не буде чекати?
кінцева причина

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-х процесорів; то заміною тестування та встановлення його реалізацією за допомогою консенсусу з 2 процесорами отримується реалізація консенсусу 3 процесорів з використанням консенсусу 2 процесорів, що неможливо. Таким чином, тестування та встановлення не можуть вирішити консенсус 3-х процесорів.

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


0

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

Визначення . Світло-консенсус досягається між n потоками iff (a) кожен потік або вирішує одне і те ж значення, або значення для нього невідоме, (b) принаймні один потік знає значення і (c) це значення було фактично запропоновано одним із нитки.

Отже, цей консенсус у його легшому розумінні дозволяє, що якась нитка не знає консенсусу, значення, яке вирішується.

Висновок : У цьому легшому сенсі тест-набір має нескінченне число консенсусу світла.

Претензія : Цей легший сенс є практичним. Наприклад, для вибору потоку для вступу в критичний розділ не потрібно створювати консенсус у суворому розумінні. Тобто, кожен потік повинен знати, вибраний він чи ні, проте якщо він не вибраний, він не повинен знати, який був обраний. Іншими словами, для взаємного виключення суворого консенсусу не потрібно, світла достатньо.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.