V>>Планировщик по умолчанию работает с пулом потоков. _>Об этом и речь.
Так пул потоков реализован как однородный пул (добро пожаловать в клуб тавтологии).
Вопрос "в каком именно потоке из пула запустится" лишён смысла целиком и полностью
Нужен контроль за приоритетами/потоками etc — пишем свой шедулер и наслаждаемся жизнью.
Здравствуйте, Vladek, Вы писали:
K>>>Под вопросом: Task.Run, Task.Factory.StartNew. _>>Эти берут потоки из пула. V>Где скажет планировщик (TaskScheduler), там и берут.
Только StartNew. Run тем и отличается, что гарантированно берет поток из пула.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, SergeyT., Вы писали:
ST>> Или еще более тонкий: а в чем разница между ThreadPool.QueueUserWorkItem и Task.Run (при учете, что таска не LongRunning)?. S>С учётом вот этого — оччень тонко
Речь о наличии work stealing-а в случае тасков и ее отсутствия в случае простого пула потоков. Т.е. и там и там один и тот же пул потоков используется, просто ж он, зараза, знает о тасках и заточен под них по другому.
Здравствуйте, SergeyT., Вы писали:
S>>С учётом вот этого — оччень тонко
ST>Речь о наличии work stealing-а в случае тасков и ее отсутствия в случае простого пула потоков
Это очень распространённое заблуждение, завязанное на нюанс текущей реализации. Спрашивать такие штуки на собеседовании можно или если принимаешь инфраструктурщика, или если оччень хочется человека завалить.
Если коротко, суть в следующем: work stealing тащит из локальных очередей. В локальные очереди на сегодня попадают _только_ задачи, запущенные из самого потока пула (про это постоянно забывают), и только если это не запрещено пользователем (например, через TaskCreationOptions.PreferFairness).
И вот тут в дело вступает сам нюанс: в момент дизайна пула задач по замерам для большинства хостов глобальная очередь не была узким местом. Это позволило отказаться от идеи "забираем из глобальной очереди пачками" и в свою очередь здорово упростило код, работающий с очередями пула.
Если глобальная очередь станет глобальной проблемой (при текущем дизайне это надо постараться) — решение откатят, задачи будут перекидываться в локальную очередь и work stealing будет работать и для итемов, запущенных через QueueUserWorkItem().
S>>>С учётом вот этого — оччень тонко
ST>>Речь о наличии work stealing-а в случае тасков и ее отсутствия в случае простого пула потоков
S>Это очень распространённое заблуждение, завязанное на нюанс текущей реализации. Спрашивать такие штуки на собеседовании можно или если принимаешь инфраструктурщика, или если оччень хочется человека завалить.
Я не понял, о каком заблуждении идет речь, ну да ладно.
По поводу спрашивать/не спрашивать.
На собеседовании есть такой тип вопросов, НЕ ОТВЕТ на которые НЕ ПОНИЖАЕТ уровень человека в глазах интервьюера, но ОТВЕТ на который СИЛЬНО ЕГО ПОВЫШАЕТ. Другими словами, если человек даже никогда не слышал о подобных ньюансах — не страшно, а вот если слышал и понимает, зачем так было сделано — это большой плюс.
ИМХО, большинство advanced технологических вопросов попадают именно в такую категорию. С их помощью, например, можно на собеседовании более адекватно оценить твой уровень и дать правильное количество плюшек
Здравствуйте, Sinix, Вы писали:
S>>>С учётом вот этого — оччень тонко
ST>>Речь о наличии work stealing-а в случае тасков и ее отсутствия в случае простого пула потоков
S>Это очень распространённое заблуждение, завязанное на нюанс текущей реализации. Спрашивать такие штуки на собеседовании можно или если принимаешь инфраструктурщика, или если оччень хочется человека завалить.
Да, и насколько я помню, work stealing, а точнее, использование локальных очередей задач из пула, сделаны для повышения кеш хитов, поскольку есть большая вероятность, что вся хрень от предыдущей задачи находится в кеше текущего ядра/процессора. А work stealing — это уже механизм контроля потенциального дисбалланса загрузки из-за оптимизации, добавленной на предыдущем этапе.
ST>Я не понял, о каком заблуждении идет речь, ну да ладно.
О вот этом
Речь о наличии work stealing-а в случае тасков и ее отсутствия в случае простого пула потоков
Заблуждение в том, что почему-то все уверены, что для пула work stealing отключен специально, а для тасков используется всегда. Примерно то же самое я слышал от трёх разных людей, первоисточник никто вспомнить не смог.
На самом деле текущее поведение не было выбрано специально, это просто следствие целого ряда решений, направленных на устранение действительно узких мест. И если спрашивать — то надо спрашивать о этих решениях, а не о частных моментах.
ST> Другими словами, если человек даже никогда не слышал о подобных ньюансах — не страшно, а вот если слышал и понимает, зачем так было сделано — это большой плюс.
На мой взгляд — нет, т.к. вопрос из серии "на собеседовании времени для правильного ответа не хватит". Потому что для правильного ответа нужен оччень большой пласт знаний, а вопрос на самом деле проверяет только краешек. У топикстартера все недавние вопросы такие, уже писал вот тут
ST>ИМХО, большинство advanced технологических вопросов попадают именно в такую категорию. С их помощью, например, можно на собеседовании более адекватно оценить твой уровень и дать правильное количество плюшек
А вот фиг. К примеру я всю эту радость забыл на отлично, поскольку в кишках тасков копался довольно давно. Чтобы выявить уровень (если мы не новичка собеседуем и если нас действительно это интересует), надо ловить не на единичных вопросах, а на сценарии, вот там-то и опыт, и знания всплывают.
