Якщо я використовую блокування, чи може мій алгоритм все-таки бути без блокування?

Поширене визначення безблокового замовлення - це те, що принаймні один процес робить прогрес. ¹

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

То чи відповідає воно визначенню без замка?

¹ Див., Наприклад, М. Герліхій, В. Лучанко та М. Муар. Синхронізація без перешкод: двосторонні черги як приклад. У розділі «Розподілені обчислення», 2003 р. «Це блокування, якщо воно забезпечує лише те, що якийсь потік завжди прогресує».

Це не визначення для блокування.

Якщо ви можете гарантувати прогрес, то у вас без тупика , і якщо у вас є можливе завершення кожного запиту, то у вас є голодування , але не блокування.

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

Я вивчав «Мистецтво багатопроцесорного програмування» ^1, і їх текст не вистачає ясності, як і книга, про яку ви посилаєтесь. Ось кілька цитат з TAMPP:

Цитата 1 (Визначення безблокового)

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

Цитата 2 (Визначення розблокування)

очікуване виклик загального методу ніколи не потрібно чекати завершення чергового виклику в очікуванні.

Цитата 3 (заявіть, що без блокування блокується)

Умови прогресу безблокування, що чекає, і без блокування гарантують, що обчислення в цілому досягає прогресу, незалежно від того, як система планує потоки.

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

Зазначимо конкретно досить невиразну фразу в цитаті 3: "незалежно від того, як система планує потоки". Цьому не передує формальний опис "системи планування потоків", тому нам залишається реконструювати її властивості, виходячи з наших попередніх уявлень про те, що повинні означати визначення :

1. система завжди виконує вказівки якогось потоку;
2. він ніколи не може виконувати вказівки будь- якого потоку;
3. всі потоки викликають розглянутий метод.

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

Виправлене визначення без замка

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

¹ Моріс Херліхі, Нір Шавіт, Мистецтво багатопроцесорного програмування, Elsevier 2008, с. 58-60

Термінологія не завжди відповідає, але я думаю, що важливо задати наступні питання щодо запропонованого алгоритму чи системи:

1. Чи є якась послідовність подій, коли потоки можуть застрягти, чекаючи один одного, навіть якщо всім потокам було дозволено весь час процесора, який вони могли використовувати [якщо так, то це не тупик безкоштовно]
2. Якщо один потік був заблокований довільно тривалий час, чи може це затримати інші потоки або погіршити роботу системи довільно довгий час [якщо так, то це не блокує].
3. Чи існує якась хоча б теоретично можлива комбінація планування потоків, яка могла б змусити всі потоки повторно повторювати одні й ті ж операції, при цьому виключаючи роботу один одного, без того, щоб хтось робив прогрес [якщо так, то це не блокування]
4. Якщо деяким потокам приділяється достатньо часу процесора відносно іншого, вони можуть змусити останній потік продовжувати повторну операцію нескінченно [якщо так, то це не чекає].

Значна частина алгоритмів без блокування полягає не в тому, що вони швидші, ніж алгоритми без блокування, а в тому, що вони не схильні до вмирання, якщо нитка отримує прокладений [зауважте, що така гарантія просто вимагає що алгоритми не блокують, але всі алгоритми без блокування є]. Можна використовувати алгоритм без блокування, але лише якщо спроби отримання блокування включають тайм-аути разом з алгоритмами, щоб гарантувати, що хтось завжди зможе досягти прогресу (наприклад, алгоритм може використовувати CompareExchangeцикл як основний метод арбітражу, але використовувати шлюзи для арбітражу доступу, коли суперечка здається високою; якщо блокування здається, що він тримається надто довго, інші потоки можуть вирішити відмовитися від використання цього блокування та замість цього створити новий.CompareExchange, якщо клієнти відмовляться від блокування, це не ставить під загрозу послідовність системи, хоча це може означати, що код, який тримав старий замок, не виконає жодної роботи, поки він занадто не відмовиться від старого блокування і не стане в порядку нового.

Ви повинні подивитися на "визначення", яке ви цитуєте в контексті :

Традиційний спосіб реалізації спільних структур даних - це використання взаємного виключення (блокування) для того, щоб паралельні операції не заважали одна одній. Блокування має ряд недоліків щодо інженерії програмного забезпечення, відмовостійкості та масштабованості (див. [8]). У відповідь дослідники досліджували різні альтернативні методи синхронізації, які не використовують взаємне виключення . Техніка синхронізації не вимагає очікування, якщо вона гарантує, що кожен потік буде продовжувати прогресувати в умовах довільної затримки (або навіть відмови) інших потоків. Він заблокований, якщо забезпечує лише те, що якась нитка завжди досягає прогресу.

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

Якщо я використовую блокування, чи може мій алгоритм все-таки бути без блокування?

Це могло бути, але це залежить від алгоритму.

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

То чи відповідає воно визначенню без замка?

Примітка сама по собі .

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

Однак, якщо ці передумови не виконуються, існує хоча б потенціал для тупиків ...

Приклад, який ви наводите, не є блокувальним з наступної причини.

Підтримка одного потоку набуває замок, і планувальник ОС призупинив потік на нескінченний період часу, тоді весь потік не може досягти прогресу, оскільки жоден не може придбати замок, придбаний підвішеною ниткою.

Взагалі кажучи, алгоритми, які використовують блокування, не є блокувальними.

Зауважте, що без тупиків та без замків - це дві різні концепції. без тупика означає, що немає можливості для глухого кута, але може існувати неполадка, яка може перешкодити всій системі прогресувати. Свобода блокування сильніша за це, оскільки це означає, що деякі потоки в системі завжди досягають прогресу з обмеженою кількістю кроків.