Bill McEwen of Amiga, Inc. writes in a public letter: "Over the last several months and in fact couple of years, Amiga has continued our software and business development and generally kept quiet. This path of quietness was chosen so that we communicated only when there was a development that culminated in a product that could be purchased. In recent weeks, our being quiet has been interpreted as weakness or an open invitation to attempt harming our business relationships and opportunities with partners and customers."

"Um... it seems someone does not know what the Amiga can do. In 1985, it came with full preemtive multitasking. I run my Amiga at 1024x768. I listen with a 5.1 audio system. The Amiga in 1985 had full motion video. I was rocking out to online mp3 streams on the Amiga earlier today."

A 1985, 7.16Mhz 68000 based, 512K (or even 1MB) OCS Amiga 1000 was not capable of FMV (e.g. 480 lines, 50 or 60 fields interlaced, 24bit color) playback. It didnít have the bus bandwidth, the video hardware fill rate, the color pallet or even the storage subsystem to support FMV playback (not even close).

What it was capable of doing was genlocking since Denise allowed control over video signal generation. This combined with the fact that Agnus and its subcomponents (including copper and blitter operations) were strictly synchronized to the timing of the video signal generated by Denise, allowed the Amiga to generate some pretty impressive graphics that were easily usable for video effects.

As for the Amiga's multitasking, AmigaOS used a simple priority driven, round-robin scheduler that was reasonably effective in its day. However it didnít perform priority deprecation or boosting for assisting CPU starved threads and could be monopolized. What most people saw as great multitasking was really a combination of the preemptive scheduler, async IO and, most importantly, separate coprocessing hardware. Regardless, modern systems have much more advanced preemptive scheduling solutions.

That youíre using your Amiga to listen to MP3's while running your desktop at 1024x768 means you have the equivalent of a decade old PC. This also means you likely have a powerup board (or an 060), some form of RTG graphics card in the box and a sound card. If it works for you, well that's great. Regardless, itís a far cry from a modern system.

Okay, letís examine why your statement is incorrect. First we will define the two common scenarios were the AmigaOS Execís scheduler can get in trouble:

1. Large number of concurrent tasks (units of execution or threads in NT) consuming large amounts of CPU time

2. One or more tasks consuming large amounts of CPU time at a higher priority

Now, letís examine number one and take a look at a screenshot ( http://i20.tinypic.com/303bczs.jpg ) of two extremely CPU intensive processes on NT (in this case Vista RTM running on a 3 Ĺ year old socket 478 uniprocessor Pentium 4 Prescott 3.2Ghz). In this screenshot you can see one has launched a 256 worker threads while the other has just two. In all cases these are basically just loops performing basic integer math. This screenshot illustrates that even with a very large number of CPU intensive threads, the scheduler is distributing CPU time and that even the sidebar, for example, is getting CPU cycles. Clearly, your statement that a simple loop at normal priority can bring the system to its knees is patently false.

Now, as to WHY dynamic priorities are important; in the second screenshot ( http://i22.tinypic.com/2vvw02e.jpg ) I have actually displayed the individual threads in the heavily threaded process to illustrate that in order to make sure that the threads are not starved, the scheduler dynamically boosts their priority. In screenshot 3 (http://i22.tinypic.com/vfbk45.jpg ), you can see that even if the process is set to run at lowest base priority class (4) while the second CPU intensive process is running full tilt two classes above it (8) to make sure that threads still making some forward progress, the scheduler boosted the priority of the circled thread all the way to the high priority class at level 15. Additional scenarios also apply for interactive threads (threads waiting on input events like mouse and keyboard events are given significant boosts of up to 6 levels in priority upon that event occurring and waking up the thread). As the thread executes, for each full quantum, its priority will decay by 1 level so eventually it will return to its base priority. Furthermore, in NT 6, the actual process quantum accounting is now cycle exact, not clock based (and ISR/DPC time is not counted against a threads quantum).

Now, in the case of the AmigaOS Exec, because it is a simple round-robin scheduler, it is possible to bring the system to its knees by simply spawning a large number of CPU intensive tasks thus flooding the scheduler. Since no mechanism exists to boost priority for either interactive threads waking on an important event or those that are starved, getting to the point of unrecoverable responsiveness while everything is at the same default priority is fully possible (not the case as demonstrated here). Furthermore, even more effective is to launch a task with a priority of over say +64 and you will effectively gain the same effect. In fairness, there was an add on extension to AmigaOS called Executive that provided a policy based feedback loop to dynamically mange scheduling and the NT scheduler has a ďrealtimeĒ priority class that can be used to monopolize the system since priority boosting never crosses the threshold into realtime priorities (24-32) (standard linux scheduler also had similar functionality, though this may have changed with CFS).

Regardless, scheduling in NT is much more advanced that the default AmigaOS Exec scheduler and no, not even 258 instances of a ďsimple loopĒ cpu intensive threads running at normal priority will bring the machine to its knees, as demonstrated in the provided screenshots (you might notice that even my dynamic wallpaper continued to update while I documented my assertions). By the way, the most common cause of a jumpy mouse cursor and poor responsiveness is the result of the cpu spending lots of time in a driver ISR at an IRQL higher than the mouse thus masking out the servicing of the lower priority interrupts, and subsequent ISRís/DPCís, as well as normal thread scheduling. This is usually due to either an incredibly bad bit of driver coding or failing hardware.