Блокирующие замки против неблокирующих замков - PullRequest
5 голосов
/ 27 февраля 2012

Я думаю здесь: если у вас есть 2 потока, выполняющих операции FAST, которые должны быть синхронизированы, разве неблокирующий подход быстрее / лучше, чем подход блокировки / переключения контекста?

Под неблокированием я имею в виду что-то вроде:

while (true) { if (checkAndGetTheLock ()) break; }

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

Как мне сбалансировать один подход с другим?

Ответы [ 2 ]

5 голосов
/ 27 февраля 2012

Вот что Параллелизм Java на практике говорит о предмете:

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

А также (что, IMO, наиболее важный момент):

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

1 голос
/ 27 февраля 2012

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

...