UStudy aims to provide Educational Content for Polytechnic College students based on the latest K Scheme syllabus of Tamil Nadu.
Types of MutlTasking:
There are 2 types of multi tasking is there that is given bellow:
Most commonly, within some scheduling scheme, one process needs to be switched out of the CPU so another process can run. Within a preemptive multitasking operating system, the scheduler allows every task to run for some certain amount of time, called its time slice.
If a process does not voluntarily yield the CPU (for example, by performing an I/O operation), a timer interrupt fires, and the operating system schedules another process for execution instead. This ensures that the CPU cannot be monopolized by any one processor-intensive application.
The term preemptive multitasking is used to distinguish a multitasking operating system, which permits preemption of tasks, from a cooperative multitasking system wherein processes or tasks must be explicitly programmed to yield when they do not need system resources.
In simple terms: Preemptive multitasking involves the use of an interrupt mechanism which suspends the currently executing process and invokes a scheduler to determine which process should execute next. Therefore all processes will get some amount of CPU time at any given time.
In preemptive multitasking, the operating system kernel can also initiate a context switch to satisfy the scheduling policy's priority constraint, thus preempting the active task. In general, preemption means "prior seizure of". When the high priority task at that instance seizes the currently running task, it is known as preemptive scheduling.
The term "preemptive multitasking" is sometimes mistakenly used when the intended meaning is more specific, referring instead to the class of scheduling policies known as time-shared scheduling, or time-sharing.
Preemptive multitasking allows the computer system to more reliably guarantee each process a regular "slice" of operating time. It also allows the system to rapidly deal with important external events like incoming data, which might require the immediate attention of one or another process.
The period of time for which a process is allowed to run in a preemptive multitasking system is generally called the time slice, or quantum. The scheduler is run once every time slice to choose the next process to run. If the time slice is too short then the scheduler will consume too much processing time.
An interrupt is scheduled to allow the operating system kernel to switch between processes when their time slices expire, effectively allowing the processor’s time to be shared between a number of tasks, giving the illusion that it is dealing with these tasks simultaneously, or concurrently. The operating system which controls such a design is called a multi-tasking system.
Examples of preemptive operating systems include AmigaOS, the Windows NT family (including XP, Vista, and Seven), Linux, *BSD, OS/2 2.X - OS/2 Warp 3 - 4.5, Mac OS X and Windows 95/98/ME (32-bit applications only). Unix and Unix-based systems, and VMS, as well as other systems used in the academic and medium-to-large business markets, have always supported preemptive multitasking, but for a long time were beyond the reach of most users either because of the costs of licensing or the expensive hardware required to support them.
Examples of older, non-preemptive (cooperative) operating systems include Windows 1.x, 2.x, 3.x, Windows for Workgroups, Windows 95/98 (when running 16-bit applications), NetWare, and Classic Mac OS versions (system 5.0 and up). Non-multitasking operating systems include older versions of Mac OS, MS DOS, and Commodore 64 OS which could only execute one program at a time.
Amiga OS, based on the preemptive multitasking TRIPOS system, was the first such system widely available to home users (1985); though some contemporary systems had access to Unix-like systems such as Xenix and Coherent, they could often be prohibitively expensive for home use. Running on Motorola 68000-based Amiga systems without memory management, the system used dynamic loading of relocatable code blocks ("hunks" in Amiga jargon) to preemptively multitask all processes in the same flat address space.
Early PC operating systems such as MS-DOS and DR-DOS, did not support multitasking at all. Novell NetWare, Microsoft Windows and OS/2 systems introduced cooperative multitasking to the PC, but did not support preemptive multitasking. In the case of the PC, the slow start was partly because of the need to support a large legacy code base of DOS software written to run in single-user mode on a 8086-based PC, whereas the Amiga system was designed to multitask from the beginning.
Nonpreemptive multitasking is a style of computer multitasking in which the operating system never initiates a context switch from a running process to another process. Such systems are either statically scheduled, most often periodic systems, or exhibit some form of cooperative multitasking, in which case the computational tasks can self-interrupt and voluntarily give control to other tasks. When non preemptive is used, a process that receives such resources can not be interrupted until it is finished.
Cooperative multitasking (Preemptive algorithm) is a type of multitasking in which the process currently controlling the CPU must offer control to other processes. It is called “cooperative” because all programs must cooperate for it to work. In contrast, preemptive multitasking forces applications to share the CPU whether they want to or not.
Some architectures (like the Intel x86 architecture) are interrupt driven. This means that if the CPU requests data from a disk, for example, it does not need to busy-wait until the read is over, it can issue the request and continue with some other execution; when the read is over, the CPU can be interrupted and presented with the read. For interrupts, a program called an interrupt handler is installed, and it is the interrupt handler that handles the interrupt from the disk.
The kernel services the interrupts in the context of the interrupted process even though it may not have caused the interrupt. The interrupted process may have been executing in user mode or in kernel mode. The kernel saves enough information so that it can later resume execution of the interrupted process and services the interrupt in kernel mode. The kernel does not spawn or schedule a special process to handle interrupts.
When a transition between user mode and kernel mode is required in an operating system, a context switch is not necessary; a mode transition is not by itself a context switch. However, depending on the operating system, a context switch may also take place at this time.