Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Mutex или SpinLock  (Прочитано 8341 раз)
0 Пользователей и 2 Гостей смотрят эту тему.
AlexCasual
Помогающий

by
Offline Offline

« : 18-05-2012 12:39 » 

Имеется список,который необходимо обойти для поиска/удаления элементов,что в данном случае лучше использовать для блокировки списка - mutex или spin-lock?
Вроде бы ограничение на спин-лок - это время его "удержания",не более 25мкс...а ведь полный проход списка может занять и больше времени...
Записан
Dimka
Деятель
Команда клуба

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 18-05-2012 12:58 » 

Собери статистику и прими решение.
Записан

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 21-05-2012 09:18 » 

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

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
resource
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #3 : 21-05-2012 20:44 » 

Печально, если для вас существуют только 2 объекта синхронизации. Никто кроме вас не сможет правильно ответить на такой вопрос, т.к. выбор объекта синхронизации очень зависит от конкретных условий.
 Что касается спинлока, то тут может быть только одна рекомендация: если можно обойтись без спинлока, то ни в коем случае не нужно его использовать. Считайте, что это непоколебимый принцип до тех пор, пока у вас возникают подобные вопросы.
Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #4 : 22-05-2012 07:55 » 

ээээ... заинтриговал) мне казалось что код спинлока при условии отсутствии коллизии выполнится быстрее... нет?

Добавлено через 9 минут и 24 секунды:
насколько я помню он повышает IRQL до DISPATCH, производит проверку в цикле с параллельной выдачей на межпроцессорную шину сигнала блокировки доступа к тому же адресу. вот не помню полностью он при этом остальные процессоры тормозит, или только на доступ к памяти переменной спинлока.
мьютекс, по-моему, тоже должен IRQL повышать, производить проверку флага мьютекса, и в случае провала переводить поток в спящее состояние. да и вообще это WFSO. еще где то неточно краем уха слышал что Event(а быть может мьютекс тоже?) предварительно в коротком цикле функционирует тоже как спинлок, для удовлетворения быстрых ожиданий.
« Последнее редактирование: 22-05-2012 09:39 от Ochkarik » Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
resource
Молодой специалист

ru
Offline Offline
Пол: Мужской

« Ответ #5 : 22-05-2012 19:42 » new

код спинлока при условии отсутствии коллизии выполнится быстрее... нет?

Захват спинлока это наверное 2 инструкции. Выполняется действительно быстро. Но это вообще никому не интересно. Гораздо интереснее другое. Чтобы захватить спинлок, надо переключиться на DISPATCH_LEVEL. В этом вся суть.

(click to show)
Если говорить о тонкостях, я лично не измерял сколько времени уходит на переключение Irql, но думается, что операция эта уже не такая быстрая как захват спинлока (без конкуренции). Достоверно известно (мне лично), что переключение Irql на разных платформах может происходить абсолютно по-разному. Но всё это тоже абсолютно не интересно  Улыбаюсь

 Зайдём не со стороны каких-то изысканий в плане производительности, а со стороны реальной практики.

 Люди во всём мире со времён зарождения Irql всячески пытаются выполнять работу на PASSIVE_LEVEL. Пишут статьи, заметки, которые обосновывают такой подход. Говорят о том, что на DISPATCH'е не доступен ввод/вывод (например файловый), что не нужно примерять на себя костюм планировщика и работать на его Irql'е, когда есть другие варианты, что не нужно пользоваться опасными методами, когда есть безопасные. Ведь в конце концов вы не знаете на какой машине, при какой нагрузке будет выполняться ваш код, и следовательно никак не можете посчитать время, которое вы проведёте под спинлоком. А ведь оно ограничено. Майкрософт распинается, придумывает рабочий поток, рабочие элементы, пишет разные статьи, best practice, всё для людей, чтоб только люди смогли обеспечить выполнение своего кода на PASSIVE_LEVEL. Люди переходят с DIRQL на DISPATCH при помощи DPC. С DISPATCH_LEVEL на PASSIVE_LEVEL. Вроде мир движется, вроде работает всё.

 Тут появляется некий мега-кодер (назовём так этого абстрактного злодея). Сидит он дома и пишет на своей "коленке" мега-код. Есть у него там обычный список с какими-то данными. Есть так же пара функций, которые вызываются операционной системой на PASSIVE_LEVEL. Казалось бы, ну как здесь можно намудрить, PASSIVE_LEVEL, все удобства, бери какой-нибудь Fast Mutex (для примера) и работай спокойно. Никаких тормозов никогда в жизни не было бы. Вместо этого мега-кодер решает, что Fast Mutex будет не так круто. Берёт спинлок, задирает себя до dispatch'а (практически до небес) и копается со своими данными как ребёнок в песочнице. Вопрос: кого за ним выслать? Дурку, чтоб подлечили или священника, чтоб грехи отпустил?

Суть в том что никогда не нужно самому залезать на DISPATCH_LEVEL.

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

Мораль: спинлок в качестве блокировки подойдёт только тогда, когда абсолютно невозможно применить что-то другое (когда ситуация такая, что больше нечего применить).
Записан
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines