From: dic5340@hertz.njit.edu (David Charlap)
Newsgroups: comp.os.os2.advocacy
Subject: Re: How many NT developers does it take to boil water?
Date: 8 Oct 92 15:00:18 GMT
Organization: New Jersey Institute of Technology, Newark, N.J.

In article <1992Oct06.003555.4423@microsoft.com> petesk@microsoft.com (Pete Skelly) writes:
>In article <1992Oct5.162850.22360@njitgw.njit.edu> dic5340@hertz.njit.edu wrote:
>> In article <1992Oct03.232108.18990@microsoft.com> petesk@microsoft.com (Pete Skelly) writes:
>> >Sit down to do something like, say, your income taxes.  Get one of those
>> >kitchen timers, and set it for 5 minutes.  Do your taxes.  When the
>> >bell goes off, reset the timer, and go read the newspaper.  When the bell
>> >goes off, reset the timer again, and watch TV.  and so on, and so on.
>> >
>> >If you don't scramble your brains after a while, I'm impressed.
....
>No, I'm implying that comparing peoples ability to "multitask" to a
>computers ability is not a good comparison.  As for cooking lunch, that's
>an IO bound task, which is where threads are useful.  It does not require
>preemptive multitasking though.

So why did you use a human example in the first place?

>> >Now, if you did have an alarm of that type, wouldn't boiling water be
>> >more equivalent to sending a request to the disk controller, and then
>> >servicing the interrupt it generates when it's done.
>> 
>> Preemptive systems work much like harware interrupts.  But you can't
>> really replace one with the other.
>
>You are correct, but thats not really the point.  Let hardware interrupts
>take care of I/O notification.  Why have preemptive MT do that.

Who said anything about preemptive MT for I/O notification?  But
interrupts only work on the OS level.  Surely, you wouldn't want user
apps catching interrupts, would you?  The OS has to get the interrupt,
then figure out who should operate.  Then the CPU is given to that
process.  If some other process is running (as is likely), why should
that process be able to keep the (now unblocked) other process from
running?  

Sure, well-written apps (like Windows apps written to the letter of
the specs - few are) will call their message handler often enough that
they'll lose the CPU to the other processes, but what about the app
that's printing and doesn't call its message handler for half an hour.
OK, it's a bad app, but why should the user (who may not have a choice
in using it) be punished for the developer's laziness?

>Let preemptive MT do what it's good at.  Let non-preemptive do what
>it's good at.  Just choose the right method for the job.  It's rather
>silly to think that one or the other is going to work for all, or
>even most cases.

Cooperation can bring the entire system down if/when one partner fails
to cooperate.  It happens among people as well as among processes.

>Could it be that the medium-to-hight end systems are doing tasks at which
>preemptive multitasking is good at?  Does that mean that preemptive multitasking
>is automatically good for low end systems to.  And for palm tops, and for
>notebooks, etc...

Preemptive multitasking is kind of silly for single-tasking
environments, as well.  Small devices like Sharp's Wizard have no use
for multitasking at all.  As for notebook PC's, they should be able to
do anything their big-brother computers can do, since they're used as
a workstation-on-the-go in most cases.
-- 
David Charlap         |"there aren't 50,000 things for which it's worth writing
dic5340@hertz.njit.edu| software; and the computer industry doesn't have enough
----------------------+ programmers to create that much good software.
Therefore, most of it must be worthless" -- Boris Beizer "The Frozen Keyboard"