Блокировка (информатика)

редактировать

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

Содержание

  • 1 Типы
  • 2 Степень детализации
  • 3 Блокировки базы данных
  • 4 Недостатки
    • 4.1 Недостаток компоновки
  • 5 Поддержка языков
  • 6 См. Также
  • 7 Ссылки
  • 8 Внешние ссылки

Типы

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

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

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

Блокировки обычно требуют аппаратной поддержки для эффективной реализации. Эта поддержка обычно принимает форму одной или нескольких атомарных инструкций, таких как «test-and-set », «fetch-and-add » или «сравнить и поменять местами ". Эти инструкции позволяют одному процессу проверить, свободна ли блокировка, и, если она свободна, получить блокировку за одну атомарную операцию.

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

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

if (lock == 0) {// блокировка свободна, установите его lock = myPID; }

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

Неосторожное использование блокировок может привести к взаимоблокировке или livelock. Чтобы избежать взаимоблокировок или живых блокировок или выйти из них, можно использовать ряд стратегий, как во время разработки, так и во время выполнения. (Наиболее распространенная стратегия состоит в том, чтобы стандартизировать последовательности получения блокировок, чтобы комбинации взаимозависимых блокировок всегда выполнялись в специально определенном «каскадном» порядке.)

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

public class Account // Это монитор аккаунта {private decimal _balance = 0; закрытый объект _balanceLock = новый объект (); public void Deposit (decimal amount) {// Только один поток одновременно может выполнять этот оператор. блокировка (_balanceLock) {_balance + = сумма; }} public void Withdraw (десятичная сумма) {// Только один поток одновременно может выполнять этот оператор. lock (_balanceLock) {_balance - = сумма; }}}

Код lock (this)может привести к проблемам, если к экземпляру можно получить доступ публично.

Подобно Java, C # также может синхронизировать методы целиком, используя атрибут MethodImplOptions.Synchronized.

[MethodImpl (MethodImplOptions.Synchronized)] public void SomeMethod () {// делать что-то}

Гранулярность

Перед тем, как вводить блокировку гранулярности, необходимо понимать три концепции блокировок:

  • накладные расходы на блокировку: дополнительные ресурсы для использования блокировок, такие как пространство памяти, выделенное для блокировок, время ЦП для инициализации и уничтожения блокировок и время для получения или снятия блокировок. Чем больше блокировок использует программа, тем больше накладных расходов, связанных с использованием;
  • блокировка конкуренция : это происходит всякий раз, когда один процесс или поток пытается получить блокировку, удерживаемую другим процессом или потоком. Чем более детализированы доступные блокировки, тем менее вероятно, что один процесс / поток запросит блокировку, удерживаемую другим. (Например, блокировка строки, а не всей таблицы, или блокировка ячейки, а не всей строки.);
  • тупик : ситуация, когда каждая из как минимум двух задач ожидает блокировки, которую другая задача держится. Если что-то не будет сделано, две задачи будут ждать вечно.

Существует компромисс между уменьшением накладных расходов на блокировку и уменьшением конфликтов блокировок при выборе количества блокировок в синхронизации.

Важным свойством блокировки является ее степень детализации. Гранулярность - это мера объема данных, которые защищает блокировка. В общем, выбор грубой степени детализации (небольшое количество блокировок, каждая из которых защищает большой сегмент данных) приводит к меньшим накладным расходам на блокировку, когда один процесс обращается к защищенным данным, но к снижению производительности, когда несколько процессов выполняются одновременно. Это связано с увеличением числа конфликтов блокировок. Чем грубее блокировка, тем выше вероятность того, что блокировка остановит выполнение несвязанного процесса. И наоборот, использование тонкой гранулярности (большее количество блокировок, каждая из которых защищает довольно небольшой объем данных) увеличивает накладные расходы самих блокировок, но снижает конкуренцию блокировок. Детализированная блокировка, при которой каждый процесс должен удерживать несколько блокировок из общего набора блокировок, может создавать тонкие зависимости блокировок. Эта тонкость может увеличить вероятность того, что программист неосознанно приведет к тупиковой ситуации.

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

Блокировка базы данных

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

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

  • Пессимистическая блокировка: пользователь, который читает запись с намерением обновить ее, устанавливает исключительную блокировку на запись, чтобы другие пользователи не могли ею манипулировать. Это означает, что никто другой не может управлять этой записью, пока пользователь не снимет блокировку. Обратной стороной является то, что пользователи могут быть заблокированы на очень долгое время, тем самым замедляя общую реакцию системы и вызывая разочарование.
Где использовать пессимистическую блокировку: это в основном используется в средах, где существует конфликт данных (степень запросов пользователей к системе базы данных в любой момент) тяжело; где стоимость защиты данных с помощью блокировок меньше стоимости отката транзакций в случае возникновения конфликтов параллелизма. Пессимистический параллелизм лучше всего реализовать, когда время блокировки будет коротким, как при программной обработке записей. Пессимистичный параллелизм требует постоянного подключения к базе данных и не является масштабируемым вариантом, когда пользователи взаимодействуют с данными, поскольку записи могут быть заблокированы на относительно длительные периоды времени. Он не подходит для использования при разработке веб-приложений.
  • Оптимистическая блокировка : это позволяет нескольким одновременным пользователям получать доступ к базе данных, в то время как система сохраняет копию начального чтения, сделанного каждым пользователем. Когда пользователь хочет обновить запись, приложение определяет, изменил ли другой пользователь запись с момента ее последнего чтения. Приложение делает это, сравнивая начальное чтение, хранящееся в памяти, с записью базы данных, чтобы проверить любые изменения, внесенные в запись. Любые расхождения между начальным чтением и записью в базе данных нарушают правила параллелизма и, следовательно, заставляют систему игнорировать любой запрос на обновление. Появляется сообщение об ошибке, и пользователя просят снова запустить процесс обновления. Это улучшает производительность базы данных за счет уменьшения количества требуемых блокировок, тем самым уменьшая нагрузку на сервер базы данных. Он эффективно работает с таблицами, требующими ограниченного обновления, поскольку ни один из пользователей не заблокирован. Однако некоторые обновления могут не работать. Обратной стороной являются постоянные сбои обновлений из-за большого количества запросов на обновление от нескольких одновременно работающих пользователей - это может расстраивать пользователей.
Где использовать оптимистичную блокировку: это уместно в средах с низкой конкуренцией за данные или при чтении - требуется только доступ к данным. Оптимистический параллелизм широко используется в.NET для удовлетворения потребностей мобильных и отключенных приложений, где блокировка строк данных на длительные периоды времени была бы невозможна. Кроме того, для поддержания блокировок записей требуется постоянное соединение с сервером базы данных, что невозможно в отключенных приложениях.

Недостатки

Защита ресурсов на основе блокировки и синхронизация потоков / процессов имеют много недостатков:

  • Конфликт : некоторые потоки / процессы должны ждать, пока не будет снята блокировка (или весь набор блокировок). Если один из потоков, удерживающих блокировку, умирает, останавливается, блокируется или входит в бесконечный цикл, другие потоки, ожидающие блокировки, могут ждать бесконечно.
  • Накладные расходы: использование блокировок увеличивает накладные расходы для каждого доступа к ресурсу, даже если вероятность столкновения очень мала. (Однако любой шанс для таких коллизий является состоянием гонки.)
  • Отладка: ошибки, связанные с блокировками, зависят от времени, могут быть очень малозаметными и чрезвычайно сложными для воспроизведения, например, взаимоблокировки.
  • Нестабильность: оптимальный баланс между накладными расходами на блокировку и конкуренцией блокировок может быть уникальным для проблемной области (приложения) и зависеть от проектирования, реализации и даже низкоуровневых изменений архитектуры системы. Эти балансы могут меняться в течение жизненного цикла приложения и могут повлечь за собой огромные изменения для обновления (повторной балансировки).
  • Компонентность: блокировки могут быть только составными (например, управление несколькими одновременными блокировками для атомарного удаления элемента X из таблицы A и вставки X в таблицу B) с относительно сложной (накладными расходами) поддержка программного обеспечения и безупречное соблюдение строгих соглашений при программировании приложений.
  • Инверсия приоритета : поток / процесс с низким приоритетом, удерживающие общую блокировку, могут помешать выполнению высокоприоритетных потоков / процессов. Приоритет inhe ritance можно использовать для уменьшения продолжительности инверсии приоритета. Протокол верхнего предела приоритета может использоваться в однопроцессорных системах для минимизации продолжительности инверсии приоритета в худшем случае, а также для предотвращения взаимоблокировки.
  • Convoying : все другие потоки должны ждать, если поток, удерживающий блокировку, отменяется из-за прерывания временного кванта или ошибки страницы.

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

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

Отсутствие возможности компоновки

Одна из блокировок Самая большая проблема программирования, основанного на блокировках, заключается в том, что «блокировки не составляют »: трудно объединить небольшие правильные модули на основе блокировок в одинаково правильные более крупные программы, не изменяя модули или, по крайней мере, не зная об их внутреннем устройстве. Саймон Пейтон Джонс (сторонник программной транзакционной памяти ) приводит следующий пример банковского приложения: разработать класс Account, который позволяет нескольким одновременным клиентам вносить или снимать деньги на счет; и дать алгоритм перевода денег с одного счета на другой. Решение первой части проблемы на основе блокировки:

класс Учетная запись: член баланс: целое число член мьютекс: Блокировка метод депозит (n: целое число) mutex.lock () баланс ← баланс + n mutex.unlock () метод вывести (n: целое число) депозит (-n)

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

функция передача (от: учетной записи, на: счет, сумма: целое число) from.withdraw (сумма) на.deposit (сумма)

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

function transfer ( from: Account, to: Account, amount: integer) if from < to // arbitrary ordering on the locks from.lock() to.lock() else to.lock () from.lock () from.withdraw (сумма) на.deposit (сумма) из.unlock () to.unlock ()

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

Поддержка языков

Языки программирования различаются по поддержке синхронизации:

  • Стандарт ISO / IEC C обеспечивает стандарт взаимное исключение (блокировки) API начиная с C11. Текущий стандарт ISO / IEC C ++ поддерживает средства потоковой передачи, начиная с C ++ 11. Стандарт OpenMP поддерживается некоторыми компиляторами и позволяет указывать критические разделы с помощью прагм. POSIX pthread API обеспечивает поддержку блокировки. Visual C ++ предоставляет атрибут synchronizeметодов для синхронизации, но это характерно для COM-объектов в Архитектура Windows и компилятор Visual C ++. C и C ++ могут легко получить доступ к любым встроенным функциям блокировки операционной системы.
  • Objective-C предоставляет ключевое слово @synchronizedдля блокировки блоков кода, а также предоставляет классы NSLock, NSRecursiveLock и NSConditionLock вместе с протоколом NSLocking для блокировки.
  • C# предоставляет ключевое слово lockв потоке, чтобы гарантировать его монопольный доступ к ресурсу.
  • VB.NET предоставляет Ключевое слово SyncLock, такое как ключевое слово C # lock.
  • Java предоставляет ключевое слово synchronizedдля блокировки блоков кода, методов или объектов и библиотеки с безопасными для параллелизма структурами данных.
  • Python предоставляет низкоуровневый механизм мьютекса с классом Lockиз threading.
  • Стандарт ISO / IEC Fortran (ISO / IEC 1539-1: 2010) предоставляет производный тип lock_typeво встроенном модуле iso_fortran_envи lock/ unlockоператоры, поскольку Fortran 2008.
  • Ruby предоставляет низкоуровневый объект mutex и без ключевого слова.
  • Ada предоставляет защищенные объекты, которые имеют видимые защищенные подпрограммы или записи, а также рандеву.
  • сборка x86 предоставляет Префикс LOCKдля определенных операций, чтобы гарантировать их атомарность.
  • PHP обеспечивает блокировку на основе файлов, а также класс Mutexв расширении pthreads.

См. Также

Ссылки

Внешние ссылки

Последняя правка сделана 2021-05-28 05:12:41
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте