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

Question

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

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

Если в компьютере только один процессор, одновременно может работать только один поток. Windows должна отслеживать объекты потока, и очень часто 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 мс в нужном месте?

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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