Каковы временные рамки между переключениями контекста в Windows?

Чтение CLR через C# 2.0 (сейчас у меня нет 3.0)

Это все еще так:

Если в компьютере есть только один ЦП, в любой момент времени может выполняться только один поток. Windows должна отслеживать объекты потока, и время от времени ей приходится решать, какой поток следует запланировать следующим для перехода к ЦП. Это дополнительный код, который должен выполняться каждые 20 миллисекунд или около того. Когда Windows заставляет ЦП прекратить выполнение кода одного потока и начать выполнение кода другого потока, мы называем это переключением контекста. Переключение контекста довольно затратно, потому что операционная система должна:

Итак, примерно CLR через C # 2.0, допустим, мы на Pentium 4 2,4 ГГц, 1 ядро, без HT, XP. Каждые 20 миллисекунд? Если поток CLR или Java сопоставляется с потоком ОС, только максимум 50 потоков в секунду могут запуститься?

Я читал, что переключение контекста происходит очень быстро в микросекундах здесь, на SO, но как часто грубо (догадки в стиле величины) скажет скромный 5-летний сервер Windows 2003 Pentium Xeon, одноядерный, дающий ОС возможность переключать контекст? 20 мс в нужном месте?

Мне не нужны точные цифры, я просто хочу убедиться, что они в нужном месте, мне кажется, что это довольно долго.


multithreading context-switching
person Community    schedule 20.05.2010    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Ваша математика «50 потоков за раз» неверна. Вы предполагаете, что каждый из этих потоков находится в состоянии 100% ЦП. Большинство потоков на самом деле спят, ожидая ввода-вывода или других событий. Даже в этом случае большинство потоков не используют все свои 20 мс, прежде чем перейти в режим ввода-вывода или иным образом отказаться от своей части.

Попробуй это. Напишите приложение с бесконечным циклом (съедает все окно процессора). Запустите 50 экземпляров. Посмотрите, как отреагирует Windows.

person Frank Krueger    schedule 20.05.2010
comment
43 потока получают доступ к ЦП при 100%. Не могу получить достаточно потоков, чтобы получить результат, когда они отказываются от общего доступа через несколько мс (сон), но 1000+ - person ; 20.05.2010
comment
ЦП 100%. Без отладчика видно 125 связанных с процессором потоков, что говорит о том, что 20 миллисекунд устарели в Windows7. На самом деле контекст exe, очевидно, переключается тысячи раз между полдюжиной внутренних потоков .net. - person ; 20.05.2010

arrow_upward
3
arrow_downward

Quantum, как его называют, зависит от нескольких вещей, в том числе от настроек производительности, которые операционная система делает по ходу работы; например, процессу переднего плана дается более высокий приоритет, и ему может быть дан [квант в 3 раза больше, чем по умолчанию. Существует также разница между SKU сервера и клиента: обычно у клиента квант по умолчанию составляет 30 мс, а у сервера — 180 мс.

Таким образом, процесс переднего плана, которому требуется столько ЦП, сколько он может получить, может получить квант 90 мс перед переключением контекста... и тогда ОС может решить, что ему не нужно переключаться, и позволить Quantum продолжить.

person Dog Ears    schedule 08.06.2011

arrow_upward
0
arrow_downward

Я только что провел тест. Я получил 43 потока, увидев свою долю за секунду (после прогрева), что делает утверждение Рихтера довольно точным (с накладными расходами), я говорю. Четырехъядерный/Win7/64bit. Да, это были 100%-ные потоки процессора, так что очевидно, что они не вернутся к своим 20 мс. Интересный

person Community    schedule 20.05.2010