Почему не блокирующий параллелизм лучше, чем блокирующий параллелизм

Question

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

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

Например, в классе ConcurrentHashMap внутри метода put() в цикле есть tryLock().Другой поток будет активен и постоянно будет пытаться проверить, снята ли блокировка или нет, потому что tryLock() - это не блокировка.Я предполагаю, что в этом случае процессор ненужно используется.

Так разве не хорошо приостановить поток, пока другой поток не завершит его выполнение, и разбудить поток после завершения работы?

Answer 1

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

По сравнению с HashTable элемент управления параллелизмом в ConcurrentHashMap разделен.Таким образом, несколько потоков могут получить блокировку (на сегментах таблицы).

Изначально класс ConcurrentHashMap поддерживает предварительно заданный уровень параллелизма, равный 32. Это позволяет одновременно выполнять максимум 32 операции put и / или remove (факторы, отличные от синхронизации, как правило, являются узкими местами, когда более 32Потоки одновременно пытаются обновить.)

Кроме того, успешные извлечения (при наличии ключа) с использованием get (ключ) и containsKey (ключ) обычно выполняются без блокировки.

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

Кроме того, размер (Методы) и isEmpty () требуют накопления в 32 управляющих сегментах и ​​поэтому могут быть немного медленнее.

Answer 2

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

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

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

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

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