On 7 Nov 2007 at 20:05, Allison wrote:
Is that an OS failure or an application failure? As
I see it and run it
NT is preemtive but applications can block or alter lower priority tasks
making it possile to do nasty thing like block keyboard task. I suspect
it's legacy plus the tendancy to make forground tasks the higher priortity
may have something to do with it.
Windows 16-bit tasks aren't preemptive, though they could have been
made so primarly because a somewhat different mindset is necessary to
write effectively for preemptive multitasking. Since the CPU can be
yanked away at any time (assuming one doesn't use critical section
declarations everywhere), one needs to manage resources so as to have
contingency plans for resources being unavailable and deadly embrace
situations. 16-bit Windows programs, as a general rule of thumb,
don't, so they must be run non-preemptively.
I've never really been sold on preemption, which seems like
"multitasking for dummies". Instead of designing an application to
yield the CPU explicitly, one must declare when the CPU cannot be
yielded--and handle resource race conditions (which darned few 32-bit
Windows programs do correctly anyway). Certainly if I were designing
for a time-critical application and had control over the entire
program base, I'd probably employ cooperative multitasking.
On many versions of Windows NT, it's possible to have a user mode
task with heavy CPU demands derail an attempt to format a floppy, for
example. The floppy driver does the bulk of its work in an
independent thread that can get messed up by Windows' scheduling--
priority-boosting the thread doesn't seem to help.
Some network functions also seem to be able to make things freeze up
in NT derivatives.
There was, I seem to recall, a Microsoft ad that showed a screenshot
of an hourglass cursor and had the blurb of "Something you'll never
see with Windows (some preemptive version)". Yeah, right.
Cheers,
Chuck