Если я использую блокировки, может ли мой алгоритм оставаться без блокировки?

Распространенным определением без блокировки является то, что по крайней мере один процесс делает успехи. ¹

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

Так соответствует ли оно определению без блокировки?

¹ См., Например, М. Херлихи, В. Лучанко и М. Моир. Синхронизация без препятствий: двусторонние очереди в качестве примера. В Distributed Computing, 2003. «Он не блокируется, если он гарантирует только то, что какой-то поток всегда делает успехи».

Это не определение для без блокировки.

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

Я подвергаю сомнению, действительно ли ваш простой пример обеспечивает это так или иначе. Вам нужны иерархии блокировок и т. Д., Чтобы действительно гарантировать прогресс, когда задействованы несколько блокировок.

Я изучал Искусство многопроцессорного программирования ^1, и их тексту не хватает ясности, как и книге, на которую вы ссылаетесь. Вот некоторые цитаты из TAMPP:

Цитата 1 (определение без блокировки)

Метод не блокируется, если он гарантирует, что бесконечно часто вызов какого-либо метода завершается за конечное число шагов.

Цитата 2 (Определение неблокирования)

ожидающий вызов метода total никогда не требуется для ожидания завершения другого ожидающего вызова.

Цитата 3 (утверждают, что блокировка без блокирования)

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

Проблема заключается в том, что утверждение в цитате 3, очевидно, не следует из определения в цитате 1. Как уже упоминалось, синхронизированная очередь, кажется, удовлетворяет цитате 1: бесконечно часто какой-либо метод успешно получает блокировку и завершается.

Обратите особое внимание на довольно расплывчатую фразу в цитате 3: «независимо от того, как система планирует потоки». Этому не предшествует какое-либо формальное описание «системы планирования потоков», поэтому нам остается реконструировать ее свойства на основе наших предварительных представлений о том, что определения должны означать:

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

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

Исправлено определение без блокировки

Метод не блокируется, если он неблокирующий, и, кроме того, гарантирует, что бесконечно часто вызов некоторого метода завершается за конечное число шагов.

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

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

1. Существует ли какая-либо последовательность событий, когда потоки могут застрять в ожидании друг друга, даже если всем потокам было разрешено все время процессора, которое они могли бы использовать [если это так, это не освобождает тупик]
2. Если один поток был заблокирован в течение произвольно долгого времени, это может привести к остановке других потоков или нарушить работу системы на произвольно долгое время [если это так, то это не неблокирует].
3. Существует ли, по крайней мере, теоретически возможная комбинация планирования потоков, которая могла бы заставить все потоки многократно повторять одни и те же операции, в то же время аннулируя работу друг друга, без какого-либо прогресса [если так, это не без блокировки]
4. Если некоторым потокам дается достаточно времени ЦП относительно другого, могут ли они заставить последний поток продолжать повторять свои операции бесконечно [если так, то он не без ожидания].

Большая часть значимости алгоритмов без блокировок заключается не в том, что они быстрее, чем алгоритмы без блокировок, а в том, что они не склонны к смерти, если поток становится отложенным [обратите внимание, что такая гарантия просто требует что алгоритмы не блокируют, но все алгоритмы без блокировки являются]. Для алгоритма без блокировки возможно использование блокировок, но только если попытки получения блокировки включают в себя тайм-ауты вместе с алгоритмами, чтобы гарантировать, что кто-то всегда сможет прогрессировать (например, алгоритм может использовать CompareExchangeцикл в качестве своего основного метод арбитража, но используйте блокировки для арбитража доступа, когда конфликт кажется высоким: если кажется, что блокировка удерживается слишком долго, другие потоки могут решить отказаться от попыток использовать эту блокировку и вместо этого создать новую.CompareExchangeотказ клиентов от блокировки не поставит под угрозу целостность системы, хотя это может означать, что код, который удерживал старую блокировку, не будет выполнять какую-либо работу до тех пор, пока он слишком не откажется от старой блокировки и не встанет в очередь для новой.

Вы должны посмотреть на «определение», которое вы цитируете в контексте :

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

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

Если я использую блокировки, может ли мой алгоритм оставаться без блокировки?

Может быть, но это зависит от алгоритма.

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

Так соответствует ли оно определению без блокировки?

Примечание само по себе .

Если шаг «делай, что он хочет» не включает в себя получение каких-либо других блокировок и гарантированно завершится за конечное время, то эта конкретная часть вашего алгоритма будет свободна от тупиковых ситуаций.

Однако, если эти предварительные условия не выполняются, существует, по крайней мере, вероятность тупиков ...

Приведенный вами пример не блокируется по следующей причине.

Поддержка одного потока получает блокировку, и планировщик ОС приостанавливает поток на бесконечный одиночный период, тогда весь поток не может выполнить процесс, поскольку никто не может получить блокировку, полученную приостановленным потоком.

Вообще говоря, алгоритмы, использующие блокировки, не свободны от блокировки.

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