A process was running on a uniprocessor system. It is being context switched. While the scheduler is performing this context switch can another process be allocated the CPU while the context switch is being performed?
0
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
10
(1) First, lets define our terms. From Wikipedia:
In computing, a context switch is the process of storing and restoring the state (more specifically, the execution context) of a process or thread so that execution can be resumed from the same point at a later time.
In other words, a context switch is the act of transfering control from one process to another. To recall the current process, the CPU has to take a snapshot of its state before allocating resources to the new process.
(2) Now let's answer exactly what get's saved. Also from Wikipedia:
registers and memory maps, updating various tables and lists, the PC, stack pointer, etc.
So, pretty much everything in the CPU needs to be stored somewhere else before loading in a new process' state.
Now let's consider your question by reasoning about two arbitrary processes, PID 1 and PID 2
PID 1 is preparing to hand the CPU to PID 2 and begins storing its state. Thus, all critical CPU elements are in use. One by one as these elements are stored, they are freed (often the timing is more complex) and the CPU can allocate those resources to PID 2.
Squeezing in an extra process would just cause overhead in the primary context switch between PID 1 and PID 2. You might even consider it a context switch inside of a context switch for any nontrivial process. Sure, if the ALU is open, it could probably do a quick calculation or two but what good would those results do when not a part of a process which is far more than just a few calculations?
Theoretically possible? Sure. Reasonable, NO. Instead of trying to use that time "lost" during a context switch, innovations focus on classifying different degrees of context switches. Basically, if you have a lightweight switch between a process, or perhaps a thread, the entire processor is not held up while doing so. For more reading, I suggest: https://en.wikipedia.org/wiki/Light-weight_process to see the difference in process types.
Clarification: The scheduler is a kernel space process.
-
-
$\begingroup$ I suppose you could say that. The scheduler is bound to the kernel space and is therefore not a process that we have direct control over even by way of superuser privileges (thankfully!). So yes, it is code and therefore a program (a process is an instance of a program), but it is not a process in the usual sense of the word. Hope this helps! $\endgroup$– user40709Commented Oct 13, 2015 at 4:49
-
$\begingroup$ So if the scheduler is a process, it should require CPU time for execution, and hence shouldn't it be using the CPU when a context switch is taking place? $\endgroup$– KevinCommented Oct 13, 2015 at 4:58
-
$\begingroup$ Excellent question! The answer is....its implementation defined. That being said, the standard assumption is that because the scheduler (a process) is a part of the OS, it will use some CPU time. Over the years, there have been lots of optimizations to avoid slowdown, most notably perhaps preemptively queuing of a number of processes so the scheduler does not need a context switch anytime a difference process needs a context switch. That would be a LOT of context switches! $\endgroup$– user40709Commented Oct 13, 2015 at 5:02
-
$\begingroup$ Try this article for more info; most of the stuff here is outside my scope: cs.rutgers.edu/~pxk/416/notes/07-scheduling.html $\endgroup$– user40709Commented Oct 13, 2015 at 5:04
$\begingroup$
$\endgroup$
The scheduler is using the CPU to perform the context switch, it is not something that is happening somewhere else, so the CPU is busy in doing the context switch and that means nothing else not even a process can do anything in the mean time.
The confusion seems to stem from the fact that we think CPU as a resource, much like other resources like memory and IO devices. Then we say that a process "uses" these resources to perform the desired operations. This way of saying things make it look like process are "real" things on their own and do stuff using resources, like a person uses different tools. This way of looking at things is just at a specific layer of abstraction. If you look at the hardware you will find that there is no thread OR process or all these abstract objects. There is only CPU and other hardware components and as soon as you switch on the system the CPU starts fetching stream of instructions and execute them. From this point of view there is no process, kernel or thread.
