Когда используется pthread_spin_lock правильная вещь (например, mutex pthread)?

Ответ 1

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

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

Точка 1 всегда будет стоять, но точки 2 и 3 имеют несколько уменьшенную полезность, если вы считаете, что хорошие реализации мьютексов, вероятно, будут вращаться приличное количество раз, прежде чем запрашивать ядро ​​для получения помощи.

Теперь, длинный ответ:

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

Как таковой, я был бы осторожен со спинлоками...: -)

Ответ 2

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

TL; DR: Это зависит.

Ответ 3

Самый безопасный метод с повышением производительности - это гибрид двух: адаптивный мьютекс.

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

Оба POSIX (PTHREAD_MUTEX_ADAPTIVE_NP) и Win32 (SetCriticalSectionSpinCount) имеют адаптивные мьютексы, на многих платформах нет API-интерфейса спин-блокировки POSIX.

Ответ 4

Spinlock имеет только интерес к контексту MP. Он используется для выполнения псевдоатомных задач. В монопроцессорной системе принцип заключается в следующем:

• Заблокировать планировщик (если задача имеет дело с прерываниями, блокировка прерываний)
• Сделайте мою атомную атаку
• Разблокировать планировщик

Но в системах MP у нас нет гарантий того, что другое ядро ​​не будет выполнять другой поток, который может войти в наш раздел кода. Чтобы предотвратить это, блокировка спина была создана, его целью является отложить выполнение других ядер, предотвращая проблему concurrency. Критическая секция становится:

• Заблокировать планировщик
• SpinLock (предотвращение ввода других ядер)
• Моя задача
• SpinUnlock
• Разблокировка задач

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