OSNews

"Even simple infinite loop with normal priority will almost completely block the NT/W2k. Even mouse cursor will move jerkily. Actually RESET button saved a lot of my nerves"

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.