> нужен какой-нибудь exponential fallback Ты уже не в первый раз употребляешь это словосочетание, как будто оно является silver bullet, позволяющей не думать о том, что там на самом деле происходит. Это не так.
> например, какой-нибудь ReaderWriterLock
Конечно он не поможет Queue. И ничему вообще из стандартной библиотеки не поможет. Потому что you are supposed to implement it yourself where it's needed! Со своими, блин, локами в своей, блин, реализации, поверх не-тред-сейф очереди или другого контейнера! Потому что никто кроме тебя не знает, что тебе нужен именно такой ReaderWriterLock!
> про привязку к стратегии квонтования которая трахает в жопу я ваще не понял.
Ну как бы это. Если у тебя есть 64 way компутер, например, как ты думаешь, когда там просыпаются треды, которые делали Thread.Sleep(1)? Уж не одновременно ли? Уж не одновременно ли все 64 треда (если ты их столько проспавнил) долго и муторно тусуются в очереди на получение ответа "да, в очереди что-то есть, одно", общего для всех, чтобы потом долго и муторно тусоваться в попытках это что-то оттуда достать, безуспешных для 63 тредов?
А если эти 63 треда потом засыпают на экспоненциально растущее время, готов ли ты объяснить, почему твоя мощная мойшина после тормозной обработки первых надцати запросов вдруг начинает обрабатывать множество последующих в один тред и не справляется с нагрузкой? Ах, все остальные экспоненциально ждут, какое экспоненциально красивое экспоненциальное архитектурное решение!
Каким образом внешний один лок с гарантированным результатом лучше внутренних двух с негарантированным я объяснил в другом комменте.
Алсо, ты так и не ответил на вопрос: ты что-нибудь можешь сказать относительно реально случающихся случаев, когда тебе хватает built-in thread-safety?
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2009-12-02 11:30 pm (UTC)Ты уже не в первый раз употребляешь это словосочетание, как будто оно является silver bullet, позволяющей не думать о том, что там на самом деле происходит. Это не так.
> например, какой-нибудь ReaderWriterLock
Конечно он не поможет Queue. И ничему вообще из стандартной библиотеки не поможет. Потому что you are supposed to implement it yourself where it's needed! Со своими, блин, локами в своей, блин, реализации, поверх не-тред-сейф очереди или другого контейнера! Потому что никто кроме тебя не знает, что тебе нужен именно такой ReaderWriterLock!
> про привязку к стратегии квонтования которая трахает в жопу я ваще не понял.
Ну как бы это. Если у тебя есть 64 way компутер, например, как ты думаешь, когда там просыпаются треды, которые делали Thread.Sleep(1)? Уж не одновременно ли? Уж не одновременно ли все 64 треда (если ты их столько проспавнил) долго и муторно тусуются в очереди на получение ответа "да, в очереди что-то есть, одно", общего для всех, чтобы потом долго и муторно тусоваться в попытках это что-то оттуда достать, безуспешных для 63 тредов?
А если эти 63 треда потом засыпают на экспоненциально растущее время, готов ли ты объяснить, почему твоя мощная мойшина после тормозной обработки первых надцати запросов вдруг начинает обрабатывать множество последующих в один тред и не справляется с нагрузкой? Ах, все остальные экспоненциально ждут, какое экспоненциально красивое экспоненциальное архитектурное решение!
Каким образом внешний один лок с гарантированным результатом лучше внутренних двух с негарантированным я объяснил в другом комменте.
Алсо, ты так и не ответил на вопрос: ты что-нибудь можешь сказать относительно реально случающихся случаев, когда тебе хватает built-in thread-safety?