I have recently started my OS course. As far as i know the work of dispatcher is to save the context of current process and load context of process to be run next. But how does it do that? When a process is preempted then as soon as dispatcher will be loaded and executed ( as it is also a program ) the context of previous process in registers, PSW etc will be lost. How is it going to save the context before loading itself ?
Asked
Active
Viewed 2.5k times
17
-
Shouldn't it be moved to superuser.com? – usr-local-ΕΨΗΕΛΩΝ Jan 24 '11 at 13:21
-
7djechelon: No, I don't think so. This is about the inner workings of an OS scheduler, not really about the use of an OS. – Bill the Lizard Jan 24 '11 at 13:52
4 Answers
20
The simple answer is that modern processors offer architectural extensions providing for several banks of registers that can be swapped in hardware, so up to X tasks get to retain their full set of registers.
The more complex answer is that the dispatcher, when triggered by an interrupt, receives the full register set of the program that was running at the time of interrupt (with the exception of the program counter, which is presumably propagated through a mutually-agreed-upon 'volatile' register or some such). Thus, the dispatcher must be carefully written to store the current state of register banks as its first operation upon being triggered. In short, the dispatcher itself has no immediate context and thus doesn't suffer from the same problem.
Here is an attempt at a simple description of what goes on during the dispatcher call:
- The program that currently has context is running on the processor. Registers, program counter, flags, stack base, etc are all appropriate for this program; with the possible exception of an operating-system-native "reserved register" or some such, nothing about the program knows anything about the dispatcher.
- The timed interrupt for dispatcher function is triggered. The only thing that happens at this point (in the vanilla architecture case) is that the program counter jumps immediately to whatever the PC address in the BIOS interrupt is listed as. This begins execution of the dispatcher's "dispatch" subroutine; everything else is left untouched, so the dispatcher sees the registers, stack, etc of the program that was previously executing.
- The dispatcher (like all programs) has a set of instructions that operate on the current register set. These instructions are written in such a way that they know that the previously executing application has left all of its state behind. The first few instructions in the dispatcher will store this state in memory somewhere.
- The dispatcher determines what the next program to have the cpu should be, takes all of its previously stored state and fills registers with it.
- The dispatcher jumps to the appropriate PC counter as listed in the task that now has its full context established on the cpu.
To (over)simplify in summary; the dispatcher doesn't need registers, all it does is write the current cpu state to a predetermined memory location, load another processes' cpu state from a predetermined memory location, and jumps to where that process left off.
Does that make it any clearer?
Mark McKenna
- 2,857
- 1
- 17
- 17
-
"when triggered by an interrupt, receives the full register set of the program that was running at the time of interrupt"...Do you mean there is some sort of hardware support which send this information and dispatcher don't have code to transfer register values ( like mov instructions...etc)? – Terminal Jan 24 '11 at 14:39
-
-
Yeah definitely!!! That was a nice explanation. Now i am also getting what paxdiablo wants to convey..:) – Terminal Jan 24 '11 at 16:35
-
"The simple answer is that modern processors offer architectural extensions providing for several banks of registers that can be swapped in hardware": What modern processors offer that, and what OSes use it? AFAIK this is more often done in software by simply storing and reloading the registers from memory. x86-32 had hardware task switching which automated this process (though still without any architectural separate bank of registers), but I believe x86-64 dropped this feature because it wasn't worth the cost. – Nate Eldredge Feb 02 '21 at 22:47
-
Hmm. I don't know what is in current production, my info is now fairly old. I know the SPARC workstations I used back in the day exposed banks of 16(?) 32b registers, and would map different banks to different processes during context switch. I understood it to be common on RISC machines. I can see how as an extension it wouldn't be that useful, if OSes would need to ship different task controllers for different architectures. – Mark McKenna Feb 04 '21 at 15:16
2
It doesn't generally get loaded in such a way that you lose the information on the current process.
Often, it's an interrupt that happens in the context of the current process.
So the dispatcher (or scheduler) can save all relevant information in a task control block of some sort before loading up that information for the next process.
This includes the register contents, stack pointer and so on.
It's worth noting that the context of the next process includes its state of being in the dispatcher interrupt itself so that, when it returns from the interrupt, it's to a totally different process.
paxdiablo
- 854,327
- 234
- 1,573
- 1,953
-
"So the dispatcher (or scheduler) can save all relevant information in a task control block of some sort before loading up that information for the next process..." That what i have doubts about....For saving all information , its PC etc values have to be loaded. Then who store the previous values? – Terminal Jan 24 '11 at 14:43
-
@Neo, take Linux as an example. There's always at least one process running which will fork the others, directly or indirectly. The OS sets things up at the start so that the switching works. As processes are started and stopped, they are added to the chain in such a way to ensure the scheduler will work okay on them. – paxdiablo Jan 24 '11 at 15:10
-
0
Dispatcher module gives control of the CPU to the process selected by the short-term scheduler; this involves: switching context, switching to user mode, jumping to the proper location in the user program to restart that program
0
The operating system's principal responsibility is controlling the execution of processes. This includes determining the pattern for execution and allocating resources to the processes.
A process may be in one of the two states :
- Running or
- Not Running
When the OS creates a new process, it creates a process control block for the process and enters that process into the system into the Not Running state. The process exists is known to OS and is waiting for an opportunity to execute.
From time to time, the currently running processes will be interrupted and the dispatcher portion of the OS will select some other processes to run.
During execution when the process is devoid of resources, it gets blocked. Provided those resources it re-enters the ready state and then into running state. This transition from ready to running state is done by dispatcher. Dispatcher dispatches the process.
