Timeline for Why was preemptive multitasking so slow in coming to consumer OS's?
Current License: CC BY-SA 4.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 29, 2018 at 22:21 | comment | added | user71659 | @PaulHK It depends on whether the cache is addressed virtually or physically. Caches that (effectively) use virtual indexing/tagging must be invalidated on context switch for correct operation. | |
| Sep 28, 2018 at 21:23 | comment | added | supercat | @NieDzejkob: Whether cache flushing would be required would depend upon whether hardware protects cache contents from inappropriate leakage. It's important to ensure that no task can be affected by cached information they're not supposed to access, but other approaches besides flushing could be used to achieve that. | |
| Sep 28, 2018 at 15:23 | comment | added | Maya | @PaulHK have you heard of Spectre and Meltdown? | |
| Sep 28, 2018 at 3:00 | comment | added | user71659 | You don't need memory protection. Mac OS 8.6 introduced opt-in preemptive multitasking, using an API that was retained well into OS X. | |
| Sep 28, 2018 at 2:25 | comment | added | supercat | @Jules: An MMU will make it such things easier for independent applications that don't need to share resources (other than a pool of fungible memory). Shared resources are still easier under a cooperative multitasking model. | |
| Sep 27, 2018 at 19:19 | comment | added | user12 | OS/2 just didn't target the 286. The 286 was designed with input from the original OS/2 group, and various modes were designed (at least in the early days) with OS/2 specifically in mind. | |
| Sep 27, 2018 at 18:23 | comment | added | user | Regarding OS/2, it's interesting to note the claim on Wikipedia that OS/2 1.x targetted the 16-bit 80286's protected mode. Again per Wikipedia, the 80286 included an on-chip MMU. | |
| Sep 27, 2018 at 11:15 | comment | added | Jules | ... releasing resources on context switch, which then becomes much easier for application developers to work with and results in fewer leaks, or even intentionally held locks. With an MMU this issue goes away ... Memory resources are virtualized and process local, so locking and unlocking is unnecessary. So without an MMU, OS designers had to decide which features to prioritize. Once MMU s became more common those decisions were no longer necessary, because we could in fact eat our cake and have it. | |
| Sep 27, 2018 at 11:10 | comment | added | Jules | @PoC - there is a relationship between them, but it isn't an obvious one. The thing is, if you want to to any advanced memory manager things (heap compaction, demand loading, swapping, etc), you either need an MMU or a way to be sure memory isnt in use before you operate on it. You can use a lock/unlock protocol, but developers don't like working with those, and often they become ineffective due to applications locking stuff for longer than necessary. In a cooperative model, you can allow programs to access resources between context switches using a simpler interface that encourages ... | |
| S Sep 27, 2018 at 9:30 | history | suggested | user6464 | CC BY-SA 4.0 |
various grammatical things
|
| Sep 27, 2018 at 8:32 | comment | added | PaulHK | Does the I&D cache need flushing on context swap (for security purposes) in a properly designed OS ? | |
| Sep 27, 2018 at 7:54 | comment | added | Jules | @tofro - yes, but on systems that have an MMU, the MMU context does need switching as part of a task switch, and in many cases that's an expensive operation, often causing dozens of essentially random memory accesses as the various TLBs are refilled. Cooperative multitaskers usually use a single MMU context even on systems that can support isolation, making them more efficient. You could do the same for a preemptive design, but there are issues with that that can cause reliability problems. | |
| Sep 27, 2018 at 7:09 | review | Suggested edits | |||
| S Sep 27, 2018 at 9:30 | |||||
| Sep 27, 2018 at 6:26 | comment | added | tofro | @PaulHK A properly designed OS will not need an MMU to context switch. The context consists of register contents only, and saving these is done by the CPU anyway. | |
| Sep 27, 2018 at 2:19 | comment | added | PaulHK | Presumably there is a higher cost on systems with an MMU in terms of how much work a context switch needs to do ? In that sense the Amiga should be able to switch tasks faster. | |
| Sep 26, 2018 at 22:10 | comment | added | supercat | @Tommy: The issue wasn't just OS data structures. Inside Macintosh specifically authorized applications to assume that memory associated with handles will only move when certain system calls are invoked, and that code which wasn't going to invoke any operations on that list didn't need to worry about memory blocks getting relocated out from under it. | |
| Sep 26, 2018 at 20:16 | comment | added | Tommy | I'd summarise the Macintosh's problem in a slightly different way: having first offered a single-tasking 128kb machine with no memory protection, it is a given that programmers would cheat and directly manipulate OS data structures. Once programmers are directly manipulating OS data structures, one cannot safely introduce preemptive multitasking because doing so would break atomicity. You'd never know when the scheduler is going to intercede with some important piece of internal structure half mutated. | |
| Sep 26, 2018 at 19:34 | comment | added | nbloqs | I had ran a fully preemptive lightweight OS such as FreeRTOS even in small 8-bit AVRs that only have a few KB of internal RAM, with no memory protection, no MMU and not protected modes at all. | |
| Sep 26, 2018 at 19:22 | comment | added | tofro | The Sinclair QL had preemptive multitasking even a year earlier. It had a 68008, thus no memory protection as well. Memory protection is no precondition for preemptive multitasking. | |
| Sep 26, 2018 at 18:45 | comment | added | PoC | The Amiga featured preemptive multitasking without memory protection. I don't think that the kind of multitasking (preemptive vs. cooperative) and memory protection are related. The Amiga also had a 68000 CPU, without MMU. | |
| Sep 26, 2018 at 18:31 | history | answered | Will Hartung | CC BY-SA 4.0 |