How long is the time frame between context switches on Windows?

Reading CLR via C# 2.0 (I dont have 3.0 with me at the moment)

Is this still the case:

If there is only one CPU in a computer, only one thread can run at any one time. Windows has to keep track of the thread objects, and every so often, Windows has to decide which thread to schedule next to go to the CPU. This is additional code that has to execute once every 20 milliseconds or so. When Windows makes a CPU stop executing one thread's code and start executing another thread's code, we call this a context switch. A context switch is fairly expensive because the operating system has to:

So circa CLR via C# 2.0 lets say we are on Pentium 4 2.4ghz 1 core non-HT, XP. Every 20 milliseconds? Where a CLR thread or Java thread is mapped to an OS thread only a maximum of 50 threads per second may get a chance to to run?

I've read that context switching is very fast in mircoseconds here on SO, but how often roughly (magnitude开发者_运维技巧 style guesses) will say a modest 5 year old server Windows 2003 Pentium Xeon single core give the OS the opportunity to context switch? 20ms in the right area?

I dont need exact figures I just want to be sure that's in the right area, seems rather long to me.

The Quantum as it's called is dependant on a few things, including performance tweaks the operating system makes as it goes along; for instance the foreground process is given a higher priority and can be given [a quantum 3 times longer than default. There is a also a difference between Server and Client SKU typically a client would have a default quantum of 30ms where a server would be 180ms.

So a foreground process that wants as much CPU as it can get may get a quantum of 90ms before a context switch.. and then the OS may decide it doesn't need to switch and let the Quantum continue.

Your "50 threads at a time" math is wrong. You assume that each of those threads is in a 100% CPU state. Most threads are in fact asleep waiting for IO or other events. Even then, most threads don't use their entire 20 ms before going into IO mode or otherwise giving up its slice.

Try this. Write an app with an inifinite loop (eats its entire CPU window). Run 50 instances of it. See how Windows reacts.

I just did a test I got 43 threads seeing its share in a second (after warming up) which makes Richter statement pretty accurate (with overhead) I say. Quadcore/Win7/64bit. Yes these were 100% cpu threads so obviously they weren't given themselves back before their 20ms. Interesting