Preemptive multitasking: Difference between revisions
(→Wimp2) |
(added approaches section) |
||
| Line 22: | Line 22: | ||
===Wimp2=== |
===Wimp2=== |
||
Wimp2, by Niall Douglas, used a different approach from previous attempts to build a PMT OS. Rather than build a PMT OS from the ground up, Wimp2 essentially ran inside of the existing OS, as a PMT environment for applications to run in. Programs could either be patched to run in the Wimp2 environment (with varying success,) or they could be recompiled for Wimp2. Incompatible programs ran outside of the Wimp2 environment. This approach has some serious issues, however. |
Wimp2, by Niall Douglas, used a different approach from previous attempts to build a PMT OS. Rather than build a PMT OS from the ground up, Wimp2 essentially ran inside of the existing OS, as a PMT environment for applications to run in. Programs could either be patched to run in the Wimp2 environment (with varying success,) or they could be recompiled for Wimp2. Incompatible programs ran outside of the Wimp2 environment. This approach has some serious issues, however. |
||
==Approaches to bringing PMT to a CMT OS== |
|||
Preemptive multitasking is a major change to a CMT environment, as applications aren't usually expecting to be preempted. There are various methods of doing this, of varying difficulty, and varying benefit. |
|||
===Directly running CMT applications in the PMT environment=== |
|||
This is by far the hardest method to do properly, although it provides the largest benefit, as existing software would get the benefits of PMT. Unfortunately, when done poorly, stability of the entire system is compromised. |
|||
WimpPatch for Wimp2 is an example of this approach. |
|||
===Virtualization=== |
|||
Virtualization involves running either applications or an OS inside of a virtual machine, a type of emulator. This approach has been used by many operating systems to run CMT (or even single-tasking) software without the issues of running them inside the main PMT environment. It's also been used for other reasons (for example, running 26-bit-only applications in a 32-bit-only environment using Aemulor) that are outside of the scope of this article. |
|||
Microsoft Windows NT uses this approach by running 16-bit Windows applications and DOS applications in a carefully designed VM, known as the NTVDM, that translates calls to Windows, DOS, and the BIOS into Windows NT calls. All applications run in the same process space. This allows these applications to run seamlessly with the main environment, albeit with the downside that interactions between virtualized programs are still subject to the problems that CMT has. |
|||
Mac OS X uses this approach to run a complete copy of Mac OS 9 on top of OS X. Old applications run inside of this virtualized copy of the old OS. This is not a very seamless approach, but it's effective. |
|||
OS/2 uses a similar approach to NT for DOS apps, although each DOS app gets its own copy of the VM. As Windows 3.1 itself is a DOS app, it's treated the same way. Special drivers are in the Windows 3.1 environment to display Windows 3.1 windows in the OS/2 environment, although it's not seamless. This is a similar approach to what Mac OS X uses. |
|||
===Running the PMT environment on top of the CMT OS=== |
|||
This is the least optimal approach for stability and performance, as a CMT application can still freeze the entire system, or reduce responsiveness. |
|||
However, it's by far the simplest method for getting PMT onto an existing CMT OS. |
|||
Windows 95, 98, and Me are the best example of this approach. The basic CMT codebase is still in place, but 32-bit applications are preempted on top of that. 16-bit applications cooperate with each other and the rest of the system. Stability is far better than that of Windows 3.1 (an almost purely CMT OS,) especially when avoiding older software, but not as good as the Windows NT family. |
|||
This approach was also used by Wimp2, although there are very few applications which natively use Wimp2. |
|||
==More info== |
==More info== |
||
Revision as of 13:34, 8 October 2009
Preemptive multitasking (or PMT for short) is a multitasking model in which the operating system takes control away from a program and gives it to another program, in order to ensure that all applications get their fair share of time. Most current operating systems use preemptive multitasking, although RISC OS does not currently use this model, instead opting for a model known as cooperative multitasking, where applications decide when to cede control to the operating system. However, there has been much discussion about the issue for many years, and there have been attempts to bring it to RISC OS.
Benefits of PMT
- A frozen program should not freeze the system, the OS should be able to take control once that program's "time slice" is over, and then you should be able to kill the frozen program, without losing anything you were working on.
- When running software that heavily loads the CPU, the rest of the system doesn't become unresponsive while the program is doing something.
- Programs don't have to be written to stop in the middle of what they're doing to preserve system responsiveness, as the OS does this for them. This makes development simpler.
Cons of PMT
- Developing a PMT OS is usually trickier than a CMT OS.
- Software in a PMT OS doesn't automatically get the whole CPU to itself for as long as it wants. That's the primary benefit of PMT, but some people consider it a disadvantage. However, with use of interrupts and priority levels, a PMT OS can usually do the tasks just as effectively, while keeping the system responsive.
Difficulties of PMT that are specific to RISC OS
Previous attempts to bring PMT to RISC OS
Gold
Gold was a project by Acorn to move RISC OS over to the Mach microkernel, which is used today by Apple as the basis of the Darwin kernel used by OS X.
Galileo
Galileo was another project by Acorn to move to a PMT OS, this time from the ground up. Galileo was cancelled with the closure of the workstation division.
Wimp2
Wimp2, by Niall Douglas, used a different approach from previous attempts to build a PMT OS. Rather than build a PMT OS from the ground up, Wimp2 essentially ran inside of the existing OS, as a PMT environment for applications to run in. Programs could either be patched to run in the Wimp2 environment (with varying success,) or they could be recompiled for Wimp2. Incompatible programs ran outside of the Wimp2 environment. This approach has some serious issues, however.
Approaches to bringing PMT to a CMT OS
Preemptive multitasking is a major change to a CMT environment, as applications aren't usually expecting to be preempted. There are various methods of doing this, of varying difficulty, and varying benefit.
Directly running CMT applications in the PMT environment
This is by far the hardest method to do properly, although it provides the largest benefit, as existing software would get the benefits of PMT. Unfortunately, when done poorly, stability of the entire system is compromised.
WimpPatch for Wimp2 is an example of this approach.
Virtualization
Virtualization involves running either applications or an OS inside of a virtual machine, a type of emulator. This approach has been used by many operating systems to run CMT (or even single-tasking) software without the issues of running them inside the main PMT environment. It's also been used for other reasons (for example, running 26-bit-only applications in a 32-bit-only environment using Aemulor) that are outside of the scope of this article.
Microsoft Windows NT uses this approach by running 16-bit Windows applications and DOS applications in a carefully designed VM, known as the NTVDM, that translates calls to Windows, DOS, and the BIOS into Windows NT calls. All applications run in the same process space. This allows these applications to run seamlessly with the main environment, albeit with the downside that interactions between virtualized programs are still subject to the problems that CMT has.
Mac OS X uses this approach to run a complete copy of Mac OS 9 on top of OS X. Old applications run inside of this virtualized copy of the old OS. This is not a very seamless approach, but it's effective.
OS/2 uses a similar approach to NT for DOS apps, although each DOS app gets its own copy of the VM. As Windows 3.1 itself is a DOS app, it's treated the same way. Special drivers are in the Windows 3.1 environment to display Windows 3.1 windows in the OS/2 environment, although it's not seamless. This is a similar approach to what Mac OS X uses.
Running the PMT environment on top of the CMT OS
This is the least optimal approach for stability and performance, as a CMT application can still freeze the entire system, or reduce responsiveness.
However, it's by far the simplest method for getting PMT onto an existing CMT OS.
Windows 95, 98, and Me are the best example of this approach. The basic CMT codebase is still in place, but 32-bit applications are preempted on top of that. 16-bit applications cooperate with each other and the rest of the system. Stability is far better than that of Windows 3.1 (an almost purely CMT OS,) especially when avoiding older software, but not as good as the Windows NT family.
This approach was also used by Wimp2, although there are very few applications which natively use Wimp2.
More info
- Wikipedia article on preemption
- Wimp2 page
- Microsoft knowledge base article on how multitasking works in Windows 95 (relevant due to similar issues existing between the Windows 3.1 to Windows 95 transition, and a transition from current versions of RISC OS to a PMT version. However, this may not be the best approach.)
