I have few doubts about how operating system works.
Scheduler: Does the scheduler runs in a separate process(like any other process). What exactly happens at the time of swapping in new process(i know the processor registers and memory tables are updated, my question is how they are updated. Can we write a program to update the registers(sc, pc) to point to a different process).
The process schedule could feasibly run in a separate process, but such a design would be very inefficient since you would have to swap from one process to the scheduling process (which would then have to make several system calls to the kernel) and then back to the new process, as opposed to just placing the scheduler in the kernel where you will not need system calls nor need to swap contexts more than once. Therefore, the scheduler is generally in the exclusive realm of the kernel.
Here are the steps that occur:
The scheduler determines which process will run in the next time slot (through various different algorithms).
The scheduler tells the Memory Managing Unit (MMU) to use the page table for the next process to run (this is done by setting a register to point to the table).
The scheduler programs the Programmable Interrupt Timer (PIT) to generate an interrupt after N clock cycles.
The scheduler restores the state of the registers from when the process was last running (or sets them to default values for new processes)
The scheduler jumps to the address of the last instruction that was not executed in the process.
After N clock cycles, an interrupt occurs and the operating system recognizes it as caused by the PIT, which is registered to be handled by the scheduler.
The scheduler saves the state of the registers (including stack pointer, etc) and grabs the program counter of where the interrupt occured (and saves it as the address to jump to next time around) and then goes back to step 1.
This is just one example of how it can be done, and many of the low level details are architecture specific. Essentially all the registers (the program state) can be saved to any place in RAM (say a linked list of structures that represent processes each having space for the registers, etc) and the virtual address space (defined by page tables) can be arbitrarily swapped out.
So essentially your question:
"Can we write a program to update the registers to point to a different process?"
is simply stated, yet the answer is correct. We sure can.
Related
1.in os when a new process comes , does hardware make interrupts (while another process is running) for os to create a new PCB data structure for this new process ?
2.Consider Completely Fair Scheduling (CFS) algorithms : when a process is running (there is one cpu core) as we know it gives priority to a process that has lowest run time until current time , consider a process that is running and the quantum does not expire yet , in this time one process s state turns to ready , Will this make interrupt (so os can reschedule) ?
thanks.
1.in os when a new process comes , does hardware make interrupts (while another process is running) for os to create a new PCB data structure for this new process ?
No; typically the hardware has no idea what any OS uses to keep track of processes (e.g. the contents and order of a PCB data structure's fields, if the OS has a PCB data structure at all, how the OS manages/keeps track of various structures, etc).
Instead, existing software typically calls a kernel system call that provides information about the new process, and the kernel constructs whatever data structures that the kernel wants.
For one possible example; an OS might have a "int SpawnProcess(char *executableFileName, char *processName, int maxThreadPriority)" function; and (when someone calls that function) the kernel might construct a PCB (and set the process name field in that structure to whatever the caller said, set the file name field, set the max thread priority, etc), then set other fields (CPU time consumed by process, number of threads belonging to process, amount of memory consumed by the process, ...) to default values; then put some kind of reference to the new PCB on some kind of a master list of processes that exist; then create a TCB (thread control block) for the process' initial thread (and set fields in that structure to default values - thread state, initial thread name, initial thread priority, signal mask, default CPU register state, etc); then put some kind of reference to the new thread in the new process' PCB; then put some kind of reference to the new thread on a scheduler queue (so that the scheduler knows the thread exists and will give it CPU time). When the scheduler actually does give the new process' initial thread some CPU time, it might start running kernel code that creates a new virtual address space, then loads the executable file and does things like dynamic linking of shared libraries (before finding the entry point from the executable file and jumping/returning to the executable's entry point). All of that is done with normal software without any special hardware features.
2.Consider Completely Fair Scheduling (CFS) algorithms : when a process is running (there is one cpu core) as we know it gives priority to a process that has lowest run time until current time , consider a process that is running and the quantum does not expire yet , in this time one process s state turns to ready , Will this make interrupt (so os can reschedule) ? thanks.
This works in the opposite order. Something will happen (a kernel system call or an IRQ) that will (eventually, after device driver and/or other kernel code does some work) cause one or more blocked tasks to unblock and become ready to run; and when that happens (e.g. when an "unblockTask(taskID task)" function in the scheduler is called by something else in the kernel) the scheduler may decide if the recently unblocked task should/shouldn't preempt the currently running task (and scheduler itself may have no clue why the task was unblocked or if any system call or interrupt was originally involved).
Currently, I am reading about Schedulers and scheduling algorithms.
I am really confused with short-term scheduler and dispatcher.
At some places, it is written that they are same. At some places, it is written that their jobs are different.
From whatever I read I concluded that - "Scheduling" of the scheduler is caused by the code associated with a hardware interrupt, or code associated with a system call. With this a mode switch from user mode to kernel mode took place. Then short-term scheduler selects a process from a queue of the available process to give it control of the CPU. The task of short-term scheduler ends here.
Now dispatcher comes into play. The dispatcher is the module that gives control of the CPU to the process selected by the short-term scheduler. This function involves the following: -Switching context -Switching to user mode -Jumping to the proper location in the user program to restart that program.
Is my understanding correct?
Suppose Process A is preempted and process B is scheduled next. What happened during the context switch ? How context data of Process
A, scheduler, dispatcher, Process B is saved and restored?
The various divisions of the process switching steps are system dependent. Operating system books like to make these steps complicated and divide the into multiple steps.
There are really only two steps:
1. pick a the new process.
2. Switch to the new process.
That last step is very simple; so simple that it is probably not worthy of being called a separate step.
Most CPUs define a structure that is usually called the Process Context Block (PBC). The PCB has a slot for every register that defines the state of the process. Switching processes can be as simple as:
SAVEPCTX pcb_address_of_current_process ; Save the state of the running process
LOADPCTX pcb_address_of_new_process ; Load the state of the other process.
REI
Some processors require more steps, like having to save floating point registers separately.
Recently, I have been reading about Operating Systems, and this bugs me a lot.
How is it really possible for one process to manage other process.
Basically a CPU simply executes instructions, after executing one instruction, then it executes the instruction at address pointed by IP and increments the IP.
Let me elaborate my doubt with an example. Lets say I have an User process (or simply a process) which is being executed by CPU. Lets say, it has 'n' instruction and currently executing 'i'th instruction. IP points to (i+1)th instruction.
So, at this point how can all other OS processes like Scheduler, dispatcher etc... comes into play, Since CPU is already executing another process.
One solution (Just a guess), I could think of is , the use of Interrupts and Interrupt Service Routines.
But its only a guess.
PS: I searched and couldn't find any satisfying answer.
With the help of the hardware, ticks causes the CPU to execute operating system code. This code checks the system state and the time that has elapsed since the beginning of this process execution. At this point, the operating system can decide to schedule a different process. All it has to do is save the current state of the running process with the process that is about to start running. (basically changing the content of the registers and saving the registers state before changing to the new process).
Eventually, the CPU is taken away even if the process doesn't want to yield it.
To address your concern, there are no operating system processes in the way you think... it isn't like there are OS processes in the queue waiting among other processes....
According to this question: Storing and retrieving process control block
PCB contains a lot of information and it is managed by the kernel (to avoid user access).
But I have question about PC and CPU registers. Is Kernel save these values every time an instruction is executed or only in context switching process?
Are PCBs linked list?
Actually, the value of CPU registers are modified as per the running sequence of instructions.
Say,the Instruction Pointer points to next instruction to be executed, the Stack Pointer,if active,would store the address of the last program request in a stack. And so on. These all are basically CPU registers!
PCB has one of the part Processor state data,which are those pieces
of information that define the status of a process when it's
suspended, allowing the OS to restart it later and still execute
correctly. This always includes the content of the CPU general-purpose
registers, the CPU process status word, stack and frame pointers etc.
During context switch, the running process is stopped and another
process is given a chance to run. The kernel must stop the execution
of the running process, copy out the values in hardware registers to
its PCB, and update the hardware registers with the values from the
PCB of the new process. // (Taken from Wikipedia)
Does Kernel save these values every time an instruction is executed or only in context switching process?
So,you might have got your question solved. The kernel only bothers saving values of hardware(CPU) registers in the case of context switching,not normally. Else,it leaves the burden on process itself to maintain the registers!
Also, the last question's answer is---The implementation of PCB is 'generally' done as a doubly linked list data structure!
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 ?
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?
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.
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
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.