since windows is multitasking OS, it must somehow switch between processes. But how is it done? Does windows include some kind of breakpoints into running programs, which should switch to other process? Becouse when program is executed, it takes control of CPU. So to enable multitasking OS must include some break instruction into the program. Am I right?
Add a comment
|
3 Answers
No, the program doesn't take complete control over the CPU. If it would, then there are other things that would stop working, like the keyboard, mouse, hard drives, et.c..
There are interrupt lines connected to the CPU, which tell it when there is information coming in from a device. A keypress for example causes an interrupt signal, which will stop the current execution and start an interrupt handler.
There is also an internal timer that is connected as a device, so the operating system can set up the timer to produce interrupt signals at a specific rate. Thus, the operating system can always get the control back from the running process at specific intervals.
The usual process when handling an interrupt is that the control returns to the running program after the interrupt handler is finished, but the process scheduler can save the state of one process, restore a different process and let the interrupt handler return to that process instead.
The scheduler also has other chances to switch between processes. For example when the program makes a system call to do disk I/O, the scheduler lets the I/O request pass through to the hardware, and saves the process in a waiting state. When the disk is ready to return data it sends an interrupt, so the scheduler can switch back to the process that is waiting for the data.
(I once wrote a program that actually took complete control over the computer and disabled all interrupts. I had to write my own handlers for keyboard and mouse input, and disk I/O doesn't work at all in that state.)
No. OSes (and threading in general) is governed by a scheduler that allocates CPU time to various threads (and processes) as necessary; the scheduler can yank the CPU away from a process wherever it sees fit.
No, it's done by the use of hardware features to get control back to the kernel on a timer or some other event.
You're describing 'cooperative multitasking', where applications are written to give control back to the OS at regular intervals. While there is an element of that when applications are waiting for user input, the network, or disk operations to complete, an OS like Windows can also run two applications that don't wait for anything at the same time.
The hardware has interrupts, which give control to a specific bit of code in the kernel that was set up during boot. The kernel then decides what to give control to next; this is the job of the scheduler.
