Context Change

When the CPU decides the process or thread has taken too long running, suspends the process or thread, and allows another to run.

Uh, CPU's don't make those decisions; OperatingSystems do. The CPU is limited to a) determining that an interrupt has occurred (including a timer interrupt used to implement pre-emption), and b) vectoring to the appropriate interrupt handlier. The rest is up to the handler--a part of the OS, usually.

Perhaps I'm being too pedantic... Mmmhh, well, yes, but it does not matter. It is the hardware that interrupts the process and then the OperatingSystem that takes over and does the actual ContextChange. The ContextChange is hard because the operatingSystem must store all the context somewhere, including the CpuRegisters?. That of course is very tricky.

It is supposed to be an expensive operation, because the process context must be changed, the context being all its memory (main memory), actually the process or thread is in main memory, so only updating the CpuRegister?s is not enough. It is more expensive when the change involves processes than when the change only involves threads in the same process.

"only"? Take a look at some real life numbers. How many machine cycles do you think a context switch takes? How many do you believe are saved for threads over processes? And of course, do you think it matters which cpu or OS we're talking about?

Comments without numbers don't mean much on this topic.