Talk:Computer multitasking
| WikiProject Computing | (Rated Start-Class, High-importance) | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|||||||||||||||||
| WikiProject Education | |||||||||||||||||
|
|||||||||||||||||
not imply unix was always multitasking
Removed: "UNIX, designed as a "single user" operating system in the 1970s, included most of the multitasking capabilities of its multi-user cousin MULTIX, and is today used for both purposes." Bad example because it is mostly untrue. Unix was very briefly a single user system, but got both multi-user and multi-tasking features very early, and at about the same time.
- Perhaps we could find a better example of multitasking being recognized as a useful feature even in a single user OS, such as a PC OS? Paragraph 8 ("Although the original purpose behind the design...") would be a good place for it. --D
thnx -Preceding unsigned comment added by 122.169.66.171 (talk) 06:27, 3 April 2010 (UTC)
change wording not imply ordering
"To remedy this situation, most time-sharing systems quickly evolved a more advanced approach known as [preemptive multitasking]?. "
In context, this reads like preemptive multitasking developed after cooperative multitasking. Preemptive multitasking was tried in the early 1960s, but it turned out to be a lot harder to do reliably than anyone expected. Remember that back then, people routinely made I/O calls from applications and grabbing control away from somebody who had just issued a read to a paper tape reader often didn't work out all that well. I'm pretty sure that cooperative multitasking was a kludge to make multitasking work better by making sure that programs were in a suspendable state when they gave up control.
I'm not sure, however, whether a change is needed or will be an improvement. - DJK
multitasking vs multiprogramming vs time sharing
It seems those three notions are intermixed here. A clarification is needed.
- Multitasking is a generic term allowing multiple tasks to be run, without regard to timing.
- Multiprogramming is the possibility for multiple programs to be ready, and waiting for the processor to be free. The initial purpose of this was to allow a second program to run while the first one waited for some I/O to complete. Multiprogramming does not require any cooperation between programs, as there were no interactive users anyway. If a program needed the CPU for a long time, it could use it.
- Time sharing is a method where all ready tasks are given a fair access to the CPU.
- It should be noted that, multi-tasking (aka time-sharing) is a type of multi-programming. A multi-programming system is not a type of multi-tasking system however.
- Multi-programming was put in place to keep the CPU busy, and not waiting on IO while it could be serving other processes.
The goal of multiprogramming is to minimize idle time for the processor, and that was the primary objective in the times the processor time was expensive.
reading from a tape
"(e.g. reading from a tape)" ?? Dated? In a modern computer would this be comparable to reading from a drive or waiting for a result from memory or an external device? - Omegatron 18:06, Oct 13, 2004 (UTC)
Merge from co-operative multitasking
weak disagree : I'd suggest that rather than merging, just add a "main article" link, as it could be argued that co-operative multitasking is a valid and reasonable article in it's own right. Guinness 11:31, 15 December 2005 (UTC)
agree : There's not a substantial amount of content in the separate article. I'd suggest that it be merged, and only split it if it later gets big enough. Currently it's mostly just redundant, and the little that's not is split across two articles. QuiTeVexat 05:59, 20 December 2005 (UTC)
observation: Preemption (computing) appears to describe the same thing also. I'm not familiar with the procedures around here, so I leave it to someone else to tag it. -- G. Gearloose (?!) 01:04, 5 February 2006 (UTC)
- I am suggesting merging preemption into deadlock. The problem is, preemptive multitasking and preemption of resources aren't exactly the same thing, although they are related. Also, I'm not sure a full article can be written on just preemption. Perhaps a split is a better choice? MagiMaster 09:04, 10 July 2006 (UTC)
Can you explain what you mean by "preemption of resources"? --Chris Purcell 17:00, 10 July 2006 (UTC)
Merge from Co-operative multitasking and Preemption (computing)
The discussion at Talk:Deadlock seems to have generated a consensus against merging. The discussion here seems to have fizzled out without it being really clear if there is a consensus. Since both of the other articles are hardly longer than the sections here and don't look like growing (in my opinion) I would propose going ahead and merging those two articles into this article. This would also help remove the Merge backlog. Any objections? --Boson 21:52, 19 October 2006 (UTC)
I/O bound / CPU bound
Surely the terms "I/O bound" and "CPU bound" aren't states of processes, but properties of a program (or a portion thereof)? (Adjectvies where a
An I/O bound process may be time-limited by the speed of its I/O, but when it cannot continue until I/O occurs then it is "blocked", whether or not it's in a busy wait. If it's waiting for a signal rather than polling, then I'd call that "waiting".
Similarly a CPU bound process is "running" (or "on the CPU"), or if not, then it's "ready".
Multithreading
"Fibers are even more lightweight than threads, and somewhat easier to program with, although they tend to lose some or all of the benefits of threads on machines with multiple processors."
There is no reference to the advantages and disadvantages of multiple cores or processers in a multitreading system, and whether multiple cores benefit or hinder other types of multitasking. This is rather important with the current surge in development of multicore processors. I don't have enough knowledge of or experience with multicore systems to edit the article - can anyone else contribute to this? --[smiler] 06:33, 16 February 2006 (UTC)
-
- I also wonder exactly what this means, I added the citation needed template 222.225.196.13 03:06, 1 August 2007 (UTC)
how could a system be designed to allow a choice of operating systems to boot from
how could a system be designed to allow a choice of operating systems to boot from?
-
- Typical multi-booting systems have a second-stage boot loader. On a PC, the second-stage boot loader sits in the MBR, and gets loaded by the BIOS.
216.23.105.20 22:41, 24 February 2007 (UTC)
Please specify
"One use for interrupts is to allow a simpler processor to simulate the dedicated I/O processors that it does not have."
I don't understand. A processor simpler than what (central or I/O?) is using interrupts to simulate the I/O processors?! -Preceding unsigned comment added by Doru001 (talk - contribs) 09:15, 16 April 2008 (UTC)
- I know what this sentence was supposed to mean, but it is completely off-topic here. See channel I/O. Deleted it.
Done --Kubanczyk (talk) 20:47, 2 July 2008 (UTC)
Amiga
I added the note on the Amiga, it seems the guys who really care about this article are not aware that there was a computer called the Amiga (most peopel think of the Amiga as a video game machine, but to those who actually used them for serious media work know better)..
There are books on the low-level programming of the system, and reading them you will realize it was a truly pre-emptive multi-tasker, and it was mentioned a lot of times by the userbase themselves, it had task priorities, it's where the eurodemos that exploit the features of the Amiga got their start.
The reason it crashed a lot and gave GURU errors was that it was expected of the developers to write their programs by the rules that Commodore laid out, and if anyone failed to manage their resources properly, the machine would crash (the result of the CPU executing beyond the code block or writing data into a code block).
This could be seen as a failure from one perspective, but from another code-purist point of view, it forced coders to write correct code that behaved and managed it's resources. If a language like java (but not as bureaucratic) had been used on the Amiga, it would not have crashed because of the elimination of pointers. It was because of the improper use of pointers and sloppiness of that coders that wrote for it, that it crashed.
To use an MPU, is to make the statement that humans are not perfect, so we should not expect to be able to write correct code either. Even when Windows 98 and Mac had MPU's, they would crash.. And computers still crash.. So in hind-sight, was the Amiga so wrong for the way it was designed, or was it more correct than any computer that has been developed since? BTW, Deluxe Paint 3 for the Amiga 1000 was around 300KB, and would run within 512KB with the Workbench and enough memory to paint pictures. When Apple attempted to make a competitor for the Amiga, they came up with the Apple IIgs (15 voice ensoniq chip with 64KB of memory and a, what was it? 1Mhz processor). And still people worship Apple like they make really good technology, look at history guyz, don't rewrite it..
97.123.57.99 (talk) 07:59, 11 August 2009 (UTC)
Alternating Multitasking
I was thinking should this topic contain topics on Alternating Multitasking, the term is not commonly used, but it describes a SIMD array processors, in which the processor tried do schedule 2 task at once by alternating sequence. So if there is 2 task, Work A and Work B. The sequences would be A, B, A, B, where task is A work, stop, work, stop. The concept is based on, overlapping the time between Task A stop and Time B work.
I know OCZ Enhanced Bandwidth and IBM Power Architecture threading uses this mechanism. Except IBM, does it a bit differently, because the instruction are very long that involves, prepare the query, fetch...etc. The time between preparition of thread is overlapped by implanting a XDR RAM. It is not really a true alternation method, but it achieve by the following
- Since it is slower at preparing threads (in Data cache), it implants a XDR RAM so it can (use that time to prepare for instruction cache and decoding) therefore the total wasted (or buffer) time is not wasted.
The only problem is that the speed that XDR RAM is not enough so it can only reach 1 petaFLOPS (or roughly tenfold) instead of at a more scalable multiple.
Usually when components are doing Alternation, it is best when one rate is faster than the order. --Ramu50 (talk) 01:45, 7 October 2008 (UTC)
Nice Article
Just want to thank everyone involved in writing this article. It's well-organized and concise, so I quickly got a good overview of the topic. Reads pretty well too, with consistent voice throughout. --Armchair info guy (talk) 03:00, 1 March 2009 (UTC)
Preemption overhead vs cooperative?
I expect that there is a certain amount of processing overhead that comes from designing a preemptive OS, due to needing to allow for a management layer that can schedule, prioritize, or idle other processes.
But I don't know if this is really true or not. It seems difficult to do an apples-to-apples performance comparison between a preemptive and a cooperative OS to know if the cooperative can use CPU cycles more efficiently by not having the management layer.
DMahalko (talk) 03:58, 3 June 2009 (UTC)
Theoretically I think there can be a very significant efficiency advantage to a cooperatively scheduled system, because of the avoidance of locking.
In a preemptively scheduled system, whenever a thread uses a shared resource (that other threads could use), it must use some mechanism of exclusion to ensure that use of the resource is not chaotically split between threads. The mechanism usually used is locking, and this typically entails significant overhead.
In theory, in a cooperatively scheduled system, threads can avoid this overhead by yielding only at times in between using shared resources. However, I say 'in theory' because in reality it is quite often the case that this is impractical. Either there would be (potentially) an unacceptably long wait between yields, or there would be a significant overhead associated with dividing up uses of the shared resource in a way that permits more frequent yields.
In the end, it isn't clear that the overhead of locking is really worse.
debater (talk) 14:28, 9 September 2009 (UTC)
Real time
I think the current 'Real time' section is a little too brief and vague:
Another reason for multitasking was in the design of real-time computing systems, where there are a number of possibly unrelated external activities needed to be controlled by a single processor system. In such systems a hierarchical interrupt system was coupled with process prioritization to ensure that key activities were given a greater share of available process time.
I propose to rewrite it as follows:
The preemptive multitasking model provides a convenient programming model for dealing with high-speed I/O.
For a long time computers have used an interrupt handling model to enable the CPU to deal with high-speed I/O events efficiently. The CPU can be doing useful work without having to poll waiting. When an event occurs, the interrupt mechanism directs the CPU to execute a interrupt handler to deal with the event. When the interrupt handler has finished, normal execution can proceed from where it was interrupted.
However, the interrupt handler is itself limited. It must never take too long to complete, because all the time it is executing it cannot itself be interrupted. To prevent the possibility of two or more simultaneous (or nearly simultaneous) events being handled too slowly, interrupt handlers must finish very quickly.
The only solution to this limitation is to have high-speed I/O events dealt with in two stages. The first stage is carried out by the interrupt handler, which performs the very minimum actions necessary to deal with the event expediently. This includes sending some signal to the second stage.
The second stage of handling is carried out by normal (interruptible) piece of software, which generally does not have any of the limitations of an interrupt handler.
The preemptive multitasking model provides a ready-made programming model for this two-stage approach, because the second stage can be a thread which blocks on a signal (e.g. a lock) controlled by the first stage (the interrupt handler).
The mechanisms for prioritization of threads can be used to control the execution of the second stages. These mechanisms may be quite sophisticated, and may be chosen for suitability for real-time applications. This can be a factor which makes a preemptive multitasking model especially convenient for some real-time applications.
Note, however, that for many 'hard' real-time applications-where responsivity needs to be tightly confined and guaranteed-preemptive multitasking is not practicable. This is currently an an area of advanced research.
I've put it here for people to review first, rather than just shoving it in.
I'm currently looking to find some references. If anyone can suggest any, I'd be grateful.
Does this article explain what a thread is? It should do!
