Advocacy
Dojo (HowTo)
Reference
Markets
Museum
News
Other
Myths
Press
General
Hack
Hardware
Interface
Software
Standards
People
Forensics
Web
CodeNames
Easter Eggs
History
Innovation
Sightings
Opinion
Martial Arts
ITIL
Thought
|
Understanding MT
MT is multi-tasking (though some people use the term to discuss multi-threading --which is a sub-set of multi-tasking) - it is when the computer pretend do more than one thing at one time. Computers can only do one thing at a time, but if they switch what they are doing, back and forth among multiple applications, they appear to be doing multiple things at once - that is multi-tasking.
There are a few forms of MT -
- CMT - Cooperative Multi-Tasking
- PMT - Pre-emptive Multi-Tasking
- Multi-threading
The different forms of multi-tasking each have their advantages and disadvantages. Throughout this discussion remember that Macs was the first mainstream personal computer to have Multi-Tasking of applications (via desk-accessories).
Cooperative Multi-Tasking - This term means that Applications "Cooperate" with each other. Every Application is written to do some stuff, and then say "I'm done for a while" - which allows the other tasks to get their turn -- and then when they are through, they too say that "I'm done". So CMT is where each application keeps as much time as it needs, and then cooperates with the other applications to give them time too.
Preemptive Multi-Tasking - This term means that System will automatically rip control away from one application, and give control to another application (it Preempts them) - then when the system desires it has had enough time, it rips control from that application and returns control to the first application. The System automatically "preempts" whatever the application are doing, and changes control based on its goals, not necessarily the applications.
Multi-Threading - A thread is a lightweight "task". It is not a whole application (process), it is usually a small part of an application (called a thread). Imagine you are using a game that has multiple characters all moving on their own - theoretically each of those guys could be doing its own thing and be a thread. Both Macs and Windows support multi-threading (though Macs did it first).
Advantages and disadvantages of each approach -
Almost all implementations of tasking have some form of "hybrids" - there are few "pure" tasking models as computers have to share devices, Memory and shared resources - so to some degree the code must "cooperate" (although, usually the system will handle that cooperation for you).
Cooperative multi-tasking has the advantage of allowing the Application to decide how much time to give to other applications. In well written apps this is often better than PMT. However, in poorly written Apps - this allows an application to be a pig and not share well. (Gets a note sent home to Mommy reading - "does not play well with others"). So cooperative multi-tasking is much more a slave to the worst written App the system is running. Since Windows seemed to have some of the worst written apps out there - Win3.1's and Win95's (with 16 bit apps) cooperative multi-tasking definitely did not work well at all ( Mac apps behave far better). It was this "low quality" issue with Windows Software that drove MS into improving their tasking model before Apple had to do the same - but there are definitely reasons for going there.
Preemptive multi-tasking has the advantage of finer
granularity. The system is constantly ripping control away
from one app and giving control to another - then yanking
control away again. This means that all application get a
smaller amount of time - but much more frequently. So things
progress more evenly. But this frequent changing of control
can, in some cases, cause a loss of overall efficiency -
although overall it usually increases it. The disadvantage
is that Applications are often not given as much control
over the scheduling, so sometimes they will have control
yanked away from them when they don't want it. (Try running
a real-time graphics intensive game under Windows with
something else running in the background to see these
results). There are also other more subtle issues with
resources and real time events that can cause problems - but
those problems have to be solved by System code writers, and
so Application code-writers don't care.
Implementations
More important than the conceptual design is the actual implementation of each.
Almost all systems have preemption at the driver level (the software that talks to the Hardware). When a hardware device needs to be serviced it preempts everything else. (This is the same for Macs and PC's).
There are Low-Level tasks and high level tasks - many systems also have preemption on the low-level tasks (like the Mac). If an application tries to steal all the time and does not share - it does not matter (in most cases) because the Mac has low-level services still running preemptively. Even with an application "not cooperating" - the low level threads often continue to work (for example the system will continue to play music, finish a download, and you can "force quit" the bad app).
So when people are discussing multi-tasking, they are usually discussing it at a higher level or Application level. When I write an application do I have to give up time, or will it be taken from me.
Macs - On the Mac the answer is that it will automatically be taken from me, unless I do something (crash or intentionally not release time) - but it is a cooperative system - it is just that much of the logic to "cooperate" is built into the system calls themselves. But application writers can use low level preemptive threads and drivers. The system also uses Multi-processing to get multiple things done at the same time.
Win3.1 - This had a form of CMT as well, but the realities of legacy code, and a system that was much more poorly documented meant that Applications were much more likely to behave poorly - and so CMT behaved very poorly on this system as well.
Win95 - This has PMT under limited circumstances - if you are running NO older Windows code (16 bit apps) and have NO 16 bit drivers - a case which is not that common - then you get PMT. Otherwise Win95 runs in CMT mode - and still has the issues like Win3.1. Some parts of Windows PMT model are not scheduled very well and have nasty artifacts - like the mouse skipping around.
WinNT - To get true PMT under windows you need to use WinNT. But then you lose much application compatibility, many of your drivers (and devices that they control) will not work, you lose plug-n-play, and you have much stiffer resource (RAM, HD) requirements.
Rhapsody - The next version of the MacOS will have PMT. Generally the later something is written, the better it gets - and Rhapsody will use the most modern scheduler of the lot.
Correcting some misunderstandings - There are some misunderstandings about PMT and CMT out there. Basically many do not understand what they are or how they are implemented, and so make some bad assumptions (reporters seem to be the worst when it comes to misinformation).
- The Mac does not preempt.
System services are preempted under the Mac. Drivers, Sound, hardware, and many low level tasks and services are preemptive. So PMT vs. CMT only applies to the application level, and what application writers must deal with - lower level tasks are automatically scheduled.
Many Application writers did go to lower level services to get their preemption done - using Time-Manager tasks, or VBL tasks which are both preemptive.
- CMT is harder (for programmers) than PMT.
CMT is not difficult to do at all. In fact GUI applications are usually event driven - meaning they get an event (mouse click, key press, menu selections) and process that event, and then wait for the next event. On the Mac - built into this "wait for next event" - is something that automatically gives time to other applications (some would say you are "preempted". Applications are also supposed to keep the user informed as to what is happening and allow other events to happen whether they have PMT or not (this is done through threading) and is part of a good design. So Application writers usually have to go out of their way to be bad and not release time when they should as the Mac will do so automatically.
- PMT is more efficient than CMT.
Actually this has more to do with implementation than inherent design. A well designed CMT system will certainly be more efficient than a poorly designed PMT system - however, the reverse is also true (good PMT is better than bad CMT). CMT also has some advantages in user control - but only in well behaved Apps, and programmers have no trust for other programmers (for reasons). PMT usually does allow finer granularity, but occasionally this causes side-effects.
Conclusion
Users do not care what form of tasking is going on - what they care about it how well it actually works in their "real-world". On the Mac multi-tasking was working before the same could be said of Windows, and it was working much better. Mac users have had the advantage of this added productivity for 10+ years, and it has only been getting better with each subsequent release of the OS - and it looks to continue to do so.
MS has made a partial jump ahead of the Macs scheduling with Win95. But it only works some of the time, and there are many other flaws that prevent it from working nearly as well as it should - and in many cases it doesn't work as well as the Macs scheduling. Most of this can be blamed on bad applications - but much also is the fault of weak-system design and implementation. Users of Windows only think they have the cat's meow in schedulers, and they are usually pressing the acronym war with "my machines got PMT, nyha, nyha, nyha". Users of both machines are usually much more pragmatic (realistic) and realize that bad PMT (or good PMT with bad applications) is not better than what the Mac has - which is multi-tasking that works, and works well.
|
