Re[3]: Userspace spinlock
От: Cyberax Марс  
Дата: 15.07.08 17:37
Оценка:
Здравствуйте, remark, Вы писали:

C>>Так как легко могут вызвать "узкие места" в загруженный системах — если система переключит поток, который держит спинлок, то другие потоки на этом спинлоке будут бесполезно способствовать глобальному потеплению. А в незагруженных один фиг проще системные мьютексы использовать.

R>Я так понимаю, что речь идёт о мьютексах с пассивным спинов, а не с активным.
С активным спином (т.е. со sched_yield) возможна ситуация, когда какой-нибудь поток может ждать сотни миллисекунд или даже секунды до получения мьютекса. А это тоже очень плохо — я сам как-то натыкался на это.
Sapienti sat!
Re[4]: Userspace spinlock
От: remark Россия http://www.1024cores.net/
Дата: 15.07.08 17:46
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, remark, Вы писали:


C>>>Так как легко могут вызвать "узкие места" в загруженный системах — если система переключит поток, который держит спинлок, то другие потоки на этом спинлоке будут бесполезно способствовать глобальному потеплению. А в незагруженных один фиг проще системные мьютексы использовать.

R>>Я так понимаю, что речь идёт о мьютексах с пассивным спинов, а не с активным.

C>С активным спином (т.е. со sched_yield) возможна ситуация, когда какой-нибудь поток может ждать сотни миллисекунд или даже секунды до получения мьютекса. А это тоже очень плохо — я сам как-то натыкался на это.


Мммм... Я запутался... Активным спином я называю, когда поток постоянно "крутится" пытаясь захватить мьютекс (ну максимум выполняя pause). Пассивным — когда поток выполняет sched_yield()/SwitchToThread() между попытками захвата.

Секунду поток может ждать и при условии, что он блокирется на примитиве ядра, типа семафора, поскольку шедулер ОС не fair, он просто работает на слишком низком уровне, что бы быть fair. Да и сами блокирующие мьютексы общего назначения не fair, они просто дают захватить мьютекс первому попавшемуся потоку, не зависимо от того сколько уже ждут другие.


1024cores — all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Userspace spinlock
От: merk Россия  
Дата: 15.07.08 18:37
Оценка:
Здравствуйте, remark, Вы писали:

R>Здравствуйте, Cyberax, Вы писали:


C>>Здравствуйте, remark, Вы писали:


C>>>>Так как легко могут вызвать "узкие места" в загруженный системах — если система переключит поток, который держит спинлок, то другие потоки на этом спинлоке будут бесполезно способствовать глобальному потеплению. А в незагруженных один фиг проще системные мьютексы использовать.

R>>>Я так понимаю, что речь идёт о мьютексах с пассивным спинов, а не с активным.

C>>С активным спином (т.е. со sched_yield) возможна ситуация, когда какой-нибудь поток может ждать сотни миллисекунд или даже секунды до получения мьютекса. А это тоже очень плохо — я сам как-то натыкался на это.


R>Мммм... Я запутался... Активным спином я называю, когда поток постоянно "крутится" пытаясь захватить мьютекс (ну максимум выполняя pause). Пассивным — когда поток выполняет sched_yield()/SwitchToThread() между попытками захвата.


R>Секунду поток может ждать и при условии, что он блокирется на примитиве ядра, типа семафора, поскольку шедулер ОС не fair, он просто работает на слишком низком уровне, что бы быть fair. Да и сами блокирующие мьютексы общего назначения не fair, они просто дают захватить мьютекс первому попавшемуся потоку, не зависимо от того сколько уже ждут другие.


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