Впрочем, в результате размышлений я пришел к выводу, что не понимаю зачем в Vista сделали данную "оптимизацию".

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

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

Но ведь это немного бредово, это стимулирует использовать критические секции неправильно - в случаях, когда блокировка происходит часто и на нее тратится много процессорного времени. При правильном же использовании критических секций, как у меня допустим - когда блокировка происходит крайне редко, эта оптимизация только вредит. Нагрузку из-за блокировок она не снижает (ввиду редкого возникновения этих блокировок), а вот отзывчивость системы резко снижает, когда редко использующему критическую секцию потоку вдруг понадобился доступ - он может простоять в очереди и МИНУТУ!!! На мой взгляд это неправильно.

Так что уважаемый guav тут может задуматься тоже. Ибо я то как раз получается использую критические секции верно и от данной оптимизации мне только хуже. Становится очевидно, что данная оптимизация в Vista как раз предназначена сгладить последствия НЕПРАВИЛЬНОГО использования критических секций. А при правильном использовании только мешает ;(

>Добежал   (27.10.08 18:18) [39]
> Причины, почему поток висит по десятку секунд я описал еще
> в самом начале ветки


:)

> Добежал   (27.10.08 18:42) [40]


Твоя задача заставить после освобождения критической секции немедленно переключится на другой поток.
А Eraser ©   (22.10.08 21:21) [1]?

Есть же другие примитивы синхронизации

1. Auto-reset event object
2. Mutex.

> Твоя задача заставить после освобождения критической секции
> немедленно переключится на другой поток


естественно. Я просто давно был уверен, что винда это делает автоматом. Она и делала так судя по всему до Vista...


> Есть же другие примитивы синхронизации


это понятно, но... ПОЧЕМУ в виста сделали такую "оптимизацию"? Тут guav начал рассуждать как это правильно, что это соответствует духу правильного использования критических секций, явно поторопясь по привычке раскритиковать обычного программиста и восхвалив MS ;)

Или это сделано для того, чтобы появился хоть один объект синхронизации без очереди потоков?

> Тут guav начал рассуждать как это правильно, что это соответствует
> духу правильного использования критических секций, явно
> поторопясь по привычке раскритиковать обычного программиста
> и восхвалив MS ;)

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

> Духу правильного использования КС соотвествует такое использование,
>  когда ожидания на КС практически нет


а его и практически нет. Не более 50мс, так как видно, что вторичный поток за секунду успевает порядка 20 раз входить и выходить из критической секции. А за 30 секунд успевает аж 600 раз входить и выходить в критическую секцию, тогда как первичный поток не получает доступа НИ РАЗУ.

Так что логика должна быть другая, имхо. Поскольку при правильном использовании критических секций блокировка редкое явление, то ДОЛЖНО происходить переключение потоков, пусть это и затратная операция, но выполняемая редко не приведет к заметному падению производительности, зато улучшит отклик.

А оптимизация vista как раз оптимизирует НЕПРАВИЛЬНОЕ использование критических секций. Ибо она поднимает производительность только лишь в случаях ЧАСТОЙ блокировки. Согласен?

> [45] Добежал   (28.10.08 23:10)
> Так что логика должна быть другая, имхо.
> Поскольку при правильном использовании критических секций блокировка редкое явление,
> то ДОЛЖНО происходить переключение потоков, пусть это и затратная операция,
> но выполняемая редко не приведет к заметному падению производительности, зато улучшит отклик.

Мое IMHO, что КС знать не знает о том в каком порядке программисту надо переключать потоки
и не должна знать об этом. Например, ты хочешь пустить первым того кто дольше ждал, а я того
у кого выше приоритет, а у Васи Пупкина очередность
вообще сложно расчитывается исходя из времени ожидания и приоритета :)
Она знает только об одном - как можно быстрее переключить. Может, если для этого есть возможность,
еще и учитывает время простоя или что-то еще.

> Riply ©   (28.10.08 23:51) [46]


> Мое IMHO, что КС знать не знает

И имхо, знать не дОлжно. Это прерогатива ОС!

> И имхо, знать не дОлжно. Это прерогатива ОС!


гениально. Критическая секция - это объект ядра windows. Если это не самая суть windows, тогда я уж не знаю.