|WikiProject Computing / CompSci||(Rated Start-class, High-importance)|
Which instance in a computer system causes the scheduler to get activated once in a while? --Abdull 14:22, 12 July 2007 (UTC)
Answer: Interrupts sent by the cpu timer causes the registered interrupt handler to run. The interrupt from the timer is Hardware IRQ0 (source: http://www.beyondlogic.org/interrupts/interupt.htm) —Preceding unsigned comment added by 220.127.116.11 (talk) 14:06, 11 May 2011 (UTC)
Please cross link each os with the scheduling algorithims that it uses. I was interested in OpenBSD scheduler, but that page says nothing in this regard. I post here because those interested in scheduling are more likely to know what is the case than those only interested in the specific os. --cant remember my password (18.104.22.168 08:51, 6 August 2007 (UTC))
More Pre-emptive Kernels
Mac OS 9 also has a preemptive kernel, site here under Mac OS 9 Threading: http://developer.apple.com/technotes/tn/tn2028.html Neskiairti (talk) 07:55, 18 December 2007 (UTC)
What about Windows 98?
Answer: Windows 98 is cooperative. It requires a process to yield in order to multitask, which is why ctrl-alt-delete was so popular. Preemption was introduced on the NT kernel.
- Note that NT predated Windows 98 by five years, but was not intended for the same market. Letdorf (talk) 19:04, 16 May 2011 (UTC).
An Alternative Answer: Windows 98 is pre-emptive, but only to the extent that exclusively Win32 applications are running. Win16 applications running on Windows 98 multitask among themselves co-operatively. However, certain critical OS resources (such as windows-drawing routines) were actually recycled 16-bit code from Windows 3.1, and they were not re-entrant. This means that if any one task was accessing those resources, it would not be safe for that task to be pre-empted by any other task trying to make use of the same resources. Whenever a Win32 application ran, it had exclusive access to the processor only for the time it spent inside those resources, otherwise it could be preempted. However, Win16 applications could not be safely preempted at any time, so they had exclusive access to the CPU right up until they decided to yield. Windows NT used a ground-up re-write of those critical OS services, guaranteeing safe re-entrancy no matter whether Win16 or Win32 applications were accessing them.22.214.171.124 (talk) 13:30, 1 October 2015 (UTC)
User preemption versus kernel preemption
It looks to me as if we're getting our knickers in a twist here over the definition of preemptive multitasking. I've removed this confusing statement:
- Linux kernels prior to Linux 2.6 were also nonpreemptive, but later releases implemented the preemptive model. Several commercial versions of UNIX are preemptive, including Solaris and IRIX. (ref: Operating System Concepts 7th edition (Pg. 195) - Silberschatz, Galvin, Gagne)
Now preemptive multitasking is pretty routine, and almost universal. Most non-toy operating systems can pre-empt a user process. Just about the only popular non-preemptive system I can think of is the old MacOS, which I suppose is conceivably still in use somewhere or other. Windows 386 had preemptive multitasking when running DOS applications on 80386 systems. Windows 3.0 had preemptive multitasking when running in "386 enhanced mode" on 80386 systems (but not on 8086 which had no protected mode operation, and sadly not the famously "brain dead" 80286 which had no way of getting out of protected mode short of resetting the chip). Windows NT, a total rewrite of Windows based on an original concept by Dave Cutler, also had it because it was never conceived as a toy. The broader UNIX family (UNIX, BSD, LINUX) have it for the same reasons.
This seems to have gotten mixed up with kernel-mode preemption, which is a different kettle of fish. When servicing a system call, many system kernels do not permit themselves to be preempted, so while the processor is servicing a system call on such a system the other processors must wait. This can have an impact on real time systems and may make a single-user system appear unresponsive in some critical situations.
This needs to be written up properly, and with more detail. --Tony Sidaway 16:05, 6 February 2008 (UTC)
- I don't think you're being accurate when you say Windows 386 (1.0, 2.0, and 3.0?) used preemptive multitasking. They used cooperative multitasking, meaning whichever task currently had the CPU (for example WordPerfect) would maintain control of said CPU until WordPerfect felt like giving it up. If WordPerfect never gave it up, then other programs (like Mosaic) never received any CPU time, which most often led to a "freeze" of the OS. THAT'S the main difference between cooperative v. preemptive multitasking: Can a program misbehave itself and hog all CPU time? In a cooperative system, it can. In a preemptive system, it can not.
- BTW: You mentioned protected-mode memory. I don't see the relevance? You can have a protected-memory CPU, and yet still have a Cooperative multitasking OS sitting on top of it. ----- Vice-versa, you can have a NON-protected-mode CPU that does preemptive multitasking. The Commodore Amiga OS ran on a 68000 CPU, and it had no protected memory of any kind, and yet the computer still did preemptive multitasking (i.e. WordPerfect would be forced to stop running, and the CPU control moved to another program like Mosaic). I think you're confusing protected/unprotected memory with preemptive/cooperative multitasking, and the two are not the same. As an OS-designer, you can mix-and-match those conditions in whatever way you want.
- Windows 386 (a specific release of Windows that preceded Windows 3.0) did have pre-emptive multitasking of DOS processes. You would have multiple DOS sessions (called "DOS boxes") and the kernel would interrupt them on a round robin scheme. Cooperative multitasking applied to Windows programs. You're perfectly correct about Windows applications being able to hog the processor because of the Windows cooperative multitasking model.
- I mention protected mode only in the context of the 80286, which was called brain-dead because the only way to get out of protected mode was to reset the processor. I'm quite familiar with AmigaOS's preemptive multitasking and aware that it didn't have any memory protection. The difference is that the Amiga was multitasking processes running code that was compiled to relocatable binary, whereas Windows was running legacy DOS code that had been compiled to absolute code and all assumed they had a whole PC to themselves. The Amiga's loader would take the relocatable binary and produce absolute code in the course of loading. A disadvantage of the Amiga's way of doing things is that applications could corrupt one another quite easily, especially if written with malice in mind. The two great advantages, which it inherited from TRIPOS, were that it could provide pre-emptive multitasking on the most basic chip in the Motorola 16-bit family, and it supported a very fast non-copying message-passing kernel.
- I'm sorry I confused you with the term "user preemption". I used this solely to distinguish preemption of processes while in user-mode from preemption of processes while executing in the kernel. By making the kernel itself preemptible the system designer improves system response at the expenses of increasing the complexity of the kernel. --Tony Sidaway 15:11, 11 February 2008 (UTC)
- I've rewritten the article in the hope of making the distinct ideas involved clearer. I've also tried to include everything about support for preemptive multitasking by various operating systems in one subsection under the main section. Please feel free to revert and discuss if this looks worse than the former version. --Tony Sidaway 15:01, 12 February 2008 (UTC)
- I've removed mention of TRIPOS as the origin of premptive multitasking on the AmigaOS. The kernel ("exec") was largely Carl Sassenrath's baby. Because a native "DOS" would not be ready in time, Commodore contracted with Metacomco who ported TRIPOS to form the basis of AmigaDOS, introducing a number of alien elements in the process, such as "handlers" (instead of "devices"), "processes" (instead of "tasks"), "packets" (instead of "messages"), or the dreaded BCPL pointers and various other oddities, but it was all layered on top of the existing kernel. 126.96.36.199 (talk) 06:11, 5 July 2010 (UTC)
Preemption or pre-emption
- Agreed. I don't know which one is "correct", but it seems like "pre-emption" is used more often from what I've seen. — FatalError 00:30, 11 January 2009 (UTC)
- It is correct without the hyphen; if you want to be anal and disambiguate the adjacent vowels, the correct but archaic way is to do what the New Yorker does: preëmption. But people worry about it and insert a hyphen frequently, though no good editor would do so. Dicklyon (talk) 03:55, 11 January 2009 (UTC)
Going from a factual to a political/judgemental tone
In the section "Systems supporting preemptive multitasking" the last paragraph states-
Preemptive multitasking is a rare example of an advanced feature of the Amiga operating system which was not found on other desktops of a similar price range during the heyday of the Amiga and as a consequence supporters of the Amiga system tend to focus an emphasis upon its importance and in doing so tend to overlook deficiencies in the Amiga computer system which led to unresolved doubts surrounding its absolute usefulness as a professional computing platform and ultimately to its downfall.
Why this change from a purely factual tone of various flavors of os and their different techniques on preemption to this judgemental comment on Amiga users? It doesn't add any valuable information to the article. I noticed there was no discussion on users who reflected fondly on OS/2 which was significantly ahead of its time and still has fans. There is no mention of NeXT and/or Nextstep/Openstep and Steve Jobs aquiring his previous company and repurposing Nextstep.
I suggest you simply drop the last paragraph from the section "Systems supporting preemptive multitasking" and add a reference to OS X evolving from Nextstep. You mention other os flavors evolving from their sources. —Preceding unsigned comment added by Georgehh (talk • contribs) 13:41, 19 August 2009 (UTC)
- history of pre-emption: invention and first application.
- hardware support for preemption —Preceding unsigned comment added by 188.8.131.52 (talk) 14:10, 11 May 2011 (UTC)
The article currently states that OS/2 never supported preemption and that it always supported preemption. From reading various articles from around the web, I believe on the latter is correct, but I am not confident enough to make the change myself. — Preceding unsigned comment added by Ozweepay (talk • contribs) 22:55, 4 May 2013 (UTC)