Re: Why Windows sucks
[snips]
On Mon, 14 Apr 2008 15:51:07 -0500, JEDIDIAH wrote:
>>> Perhaps I should have clarified. I'm talking about true multitasking,
>>
>> No such thing.
>
> I dunno. The original x86 was pretty dang primitive.
Not nearly as primitive as the 6502, which the C64 was based on - and
*it* handled multitasking quite handily.
>> Cooperative, round-robin, pre-emptive, they _all_ qualify as
>> multitasking, the only differences being the comparative efficiency and
>> the response to apps which become unresponsive.
>
> Even in the 80s and early 90s, any system that wasn't fully
> pre-emptive
> and also came with memory protection would be referred to as they were
> more like fakes than the real thing.
By whom?
No, seriously, by whom? They all qualify as multitasking, the only
significant differences are in efficiency and how they handle
uncooperative applications.
> Everyone seemed to acknowledge the
> rather big caveats involved and never placed the cooperative systems on
> anywhere the same footing as the fully pre-emptive ones.
Sure, because a cooperative multitasker was just that - cooperative. It
required that the applications actually cooperate, and it could be
hellishly difficult to design 'em to do so in some cases.
Preemptive tasking removed that need - if your app doesn't cooperate, we
don't care, because *zot* you've just been yanked out of the active state
and something else is running.
They're both multitasking, one's simply more effective.
Take a hypothetical example of cooperative tasking between apps A and B,
and a resource R.
A is scheduled and requests resource R, which is free. It gets the
resource which now is marked "busy". It may well use this resource for
some time, so, being a nice little program, it releases the CPU every now
and then.
B gets scheduled, attempts to get resource R, which is busy, but there's
a glitch in B's resource management code: it only releases the CPU
("cooperates") *after* it gets the resource. Until then, it waits for
the resource to be available - meaning it is now stuck in a perpetual
wait state, as R is busy and B doesn't release the CPU, meaning A never
finishes its job and never releases R.
Net result, R is locked, B never finishes, A never finishes, all not good.
Now take away the cooperative aspect:
A runs, locks R.
B runs, requests R, which is locked.
B goes into a "forced" wait state.
A finishes, releases R.
B is now woken up and scheduled, it gets R, all is good.
Both systems allow multiple "simultaneous"[1] tasks to run, but one is
less fragile. Each multitasks, one is simply better at it.
Multitasking is simply the illusion - and occasionally the reality - of
running several programs at the same time. Such illusion - even such
reality - can be achieved by any number of means, including cooperative
and round-robin tasking. They're no more or less "multitasking" than any
other approach, they're just more fragile and/or less efficient than some
other apporaches.
[1] "simultaneous" in quotes because unless there's actually multiple
execution paths on the processor, or you have multiple processors, only
one task ever actually executes at a time.