Когда структуры данных без блокировки менее производительны, чем взаимные исключения (мьютексы)?

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

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

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

Обратите внимание, что в некоторых средах уровень блокировки выше установленного. Мьютекс, предоставляемый ОС; поведение мьютекса,

Я хотел бы добавить один пункт к этой части ответа: «Когда мьютекс или критическая секция работают медленно, это когда получение блокировки не удается (существует конфликт). В этом случае ОС также вызывает планировщик, чтобы приостановить поток до тех пор, пока объект исключения не будет освобожден».

Кажется, как и в разных операционных системах, могут быть разные подходы к тому, что делать в случае сбоя получения блокировки. Я использую HP-UX, и у него, например, более сложный подход к блокировке мьютексов. Вот его описание:

... С другой стороны, изменение контекста - дорогостоящий процесс. Если ожидание будет коротким, мы не хотели бы переключать контекст. Чтобы сбалансировать эти требования, когда мы пытаемся получить семафор и обнаруживаем, что он заблокирован, первое, что мы делаем - это короткое ожидание вращения. Подпрограмма psema_spin_1 () вызывается для вращения до 50 000 тактов, пытаясь получить блокировку. Если нам не удается получить блокировку после 50 000 циклов, мы вызываем psema_switch_1 (), чтобы отказаться от процессора и позволить другому процессу взять его на себя.

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

Лучше подумать, нужно ли разрешить нескольким потокам ждать доступа к некоторому набору операций или блокировать, пока не появится сигнал. Для каждого требуется очередь ожидающих потоков. Первый ставит в очередь потоки, ожидающие доступа к синхронизированной области, а второй ставит в очередь потоки, ожидающие сигнала. Классы Java AbstractQueuedSynchronizer и AbstractQueuedLongSynchronizer предоставляют такую ​​очередь, в частности, CLH Queue , на которой можно строить мьютексы, условия и другие очереди на основе примитивы.

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