When talking about the scheduler in operating systems. Everytime a process is been executed the operating system gives it a quantum (the maximum time it can be executed without calling de scheduler). My doubt is, when the quantum expires, the next quantum is automatically started, or it waits for the context switch to be completely done to start?
Related
My entire application's state depends on the quartz scheduler.
I am running a daily job which runs every 24 hours and updates the application state based on the logic written in job's execution function.
While testing, I found that sometimes when the system gets heavily loaded, scheduler do not work and the state does not change.
When I was running scheduler for every second and keeps system heavily loaded I was able to reproduce this case frequently.
Is there any way to ensure that quartz scheduler is running always?
What causes transition of process from one state to another state if non-preemptive multitasking scheme is being used to manage multiple tasks in the system?
Suppose a process is in running state. Now it moves to waiting state for I/O. In that case, another ready process will be context switched and will be executed.
Could you run software in conjunction with the OS? although it might not be very practical, I am curious to know if there are any limitations that deem this impossible without regards to performance, ... etc. The way in which I could visualize the system functioning would be in the same manner in which the OS gives the illusion that multiple programs are executed at the same time in order to multitask when in reality only one program operates at a time, but in this case, it is not just the OS and the processes executing on the processor, but a program and a OS at the same time. The processor architecture which I would based this design on would be the x86.
At its core, a multitasking OS is nothing more than a task switcher. There are two kinds of multitasking which usually exist in parallel - co-operative (like windows 3.1) where the program is responsible for sharing resources (either "I'm waiting for this so do something else in the meantime" or "Give someone else a chance for a while") and preemptive where the OS steps in and says "You've had enough time, now give someone else a chance."
Even the most primitive CPUs have interrupts. Something happens (a key is pressed or a timer goes off) and a function is called to do something before returning to what it was doing. The return from interrupt command restores the registers and returns to the exact instruction that was about to be executed when the interrupt happened.
However, it does not have to return to the same place. When entering the interrupt routine, the return address and registers are on the stack. Take them off and save them somewhere referenced by the current task. Now take those you saved earlier from a different task and put those on the stack (return address last). Now returning from the interrupt will continue executing the task from earlier. You might also want to set a timer before you leave to set a time limit before switching tasks again.
That's the simplest form of task-switching as you describe.
I'm not quite understanding one sentence from WIKI about the System Call "The operating system executes at the highest level of privilege, and allows applications to request services via system calls, which are often executed via interrupts; an interrupt automatically puts the CPU into some required privilege level, and then passes control to the kernel, which determines whether the calling program should be granted the requested service."
How physically can an CPU be put into a certain privilege level and what does it mean by passing the control to kernel? Please explain these in the CPU-registers level.
This is an excellent question and privilege levels are one of the most beautiful concepts of Operating Systems.
This forum however is not the right place to ask.
However since you've asked, I'll paint you a general picture. Now you know that the OS does a lot of scheduling of processes. The scheduler must be called at periodic intervals. The CPU maintains a counter which causes a Timer interrupt.
The code which handles the Timer interrupt calls the scheduler. Now during scheduling OS level data structures are modified (process queues, etc.). At this point, if the user program were to be active for some reason, it can mess with those data structures leading to a crash.
This is handled via privilege levels. So, during scheduling, the CPU is said to be in a privilege mode - the kernel mode. The user programs can't access the CPU now.
Here comes the awesome part now. If suppose this switch in privilege level was to be made by the software, if there was a command, it could potentially be exploited by malicious user programs.
For this reason, we can't rely on the software to do the switch. We need hardware support.
The hardware is designed so that receiving interrupts sets the "privilege bit register". When the interrupt code is finished (scheduling is done), the return causes the hardware to clear the bit.
The interrupt handling code is located in a protected area in the memory reserved for OS code. User programs can't access this code (If it tries to access that part of the memory, an exception is thrown by the hardware).
Thus sanity is preserved.
How is the multitasking implemented at the basic level ? To clarify my question, lets say we are given a C runtime to make an application which implements multitasking, which can run only one task at a time on a single core processor, say, by calling main() function of this "mutlitasking" application.
How do standard OS kernels implement this ? How does this change with multicore processors
OS sets an interrupt timer, and lets the program run. Once the timer expires, control flow jumps to code of the OS for context switch.
On the context switch OS saves registers and supporting data of the current process and replaces it in CPU with data of the next process in queue. Then it sets another interrupt timer and let the next program run from where it was interrupted.
Also a system call from the current process gives control to the OS to decide if it is time for a context switch (eq. process is waiting for an IO operation)
The mechanics is transparent for programs.
Run. Switch. Repeat. :)
I've not done much work with multi-core processors, so I will refrain from attempting to answer that part of the query. However, with uniprocessors, two strategies come to mind when it comes to multi-tasking.
If I remember correctly, the x86 supports hardware task switching. (I've had minimal experience with this type of multi-tasking.) From what I recall, when the processor detects the conditions for a task switch, it automatically saves all the registers of the outgoing task into its Task State Segment (x86), and loads all the registers from the incoming task's Task State Segment. There are various caveats and limitations with this approach such as the 'busy bit' being set and only being able to switched back to a 'busy task' under special conditions. Personally, I do not find this method to be particularly useful to me.
The more common solution that I have seen is task switching by software. This, can be broken down into cooperative task switching and pre-emptive task switching. If you are coding up a cooperative task switching strategy, a task switch only occurs when the task voluntarily gives up the processor. In this strategy, you only need to save and load the non-volatile registers. If a pre-emptive strategy is chosen, then a task switch can occur either voluntarily, or non-voluntarily. In this case, all the registers must be saved and loaded. When coding either scenario, you have to pay extra care that you do not corrupt your register contents and that you set up your stack correctly so that when you return from task-switching code you are at the right place on the stack of the incoming task.
Hope this helps.