🚀 go-pugleaf

In article <nevin-0709950221230001@mac-nevin.cs.arizona.edu>,
Nevin ":-]" Liber <nevin@CS.Arizona.EDU> wrote:
>In article <19950904.1178078.10576@olympus.net>, dons@olympus.net (Don
>Schmelling) wrote:
>
>> Nevin ":-]" Liber (nevin@CS.Arizona.EDU) wrote:
>> : In article <19950903.1175360.FCDB@olympus.net>, dons@olympus.net (Don
>> : Schmelling) wrote:
>
>> : > Nevin ":-]" Liber (nevin@CS.Arizona.EDU) wrote:
>> : >I do not think of all
>> : > end-users as dumb, just the ones that are.
>

[Car Trivia, and Webster's definition of indispensible deleted as
 a useless waste of bandwidth.]

>> CMT is not real multitasking, oh sure it may possibly multitask some
>> applications, but it is not true multitasking.  To get true multitasking
>> you need something like PMT.
>
>Great.  You are just another person who gets all of his knowledge from
>reading Usenet.  I suppose the religion you belong to is the one true
>religion, too.  Can you cite even one source in a respected computer
>journal / book that equates PMT with "true" multitasking?  I can cite you
>sources on concurrent programming and operating systems (eg: Greg Andrews
>book the Principles of Concurrent Programming) that talk about and use the
>words cooperative multitasking, and they don't consider it to be "false"
>or "fake" multitasking (nor do they mention DOS, Windows, or the
>Macintosh).  I've been asking anyone on Usenet to cite a source for three
>years now; no one has yet done it.

Don't be so retarded.  There's been many arguments which have argued the
the academic definitions of multitasking, and how they apply to the real
world. 

>I have a little secret for you:  the only difference between CMT and PMT
>is how tasks get swapped; ie, the whether scheduling is under application
>control or OS control.  Neither solution is perfect.  CMT apps have to
>guess about what the rest of the system is doing; PMT OSes have to guess
>about what all the apps are doing.  Some PMT schedulers, such as the one
>in Copland, will be better at doing this, since the apps will cooperate by
>telling the OS exactly what kind of task it is (UI, CPU-bound, etc.);
>schedulers rarely get this right using heuristics alone (such as the Unix
>scheduler).

Oooh.  "Heuristics?"  Get real.  You've just mentioned the best thing
about PMT without even knowing it.  You say that "PMT OSes have to guess
about what all the apps are doing," which is patently FALSE.  BZZT!  
WRONG!  A PMT operating system will preempt one process and cause another,
which is queued depending on a priority schedule, to execute until it is
preemted by another process.  Each process has *no idea* that there is 
another process executing.  

You've touched on another topic as well, and that is the extended hardware
requirement that goes with PMT.  SCSI controllers, for example, will 
allow storage requests to be handled separately without the CPU watching
so that the rest of the machine is able to utilize the few milliseconds
required for the rest of the system to maintain fluidity.  SMT multi-
processing is another method to 'smooth out the wrinkles.'  

And finally, you attempt to even suggest that CMT is nearly equal to
PMT, and that neither are perfect.  Well, with the limited hardware
we have, such as single disk/cpu machines, PMT multitasking operating
systems *are the best mankind has got to offer us!*  So, why not just
believe it's the perfect solution?  As to CMT, imagine the scenario 
where a file containing 10,000 records is to be indexed (or even consider
the header shuffling of Forte' Agent newsreader).  To provide a semblance
of multitasking, the routine would have to have various exit points within
the indexing routine at when the process may return to the message loop 
and allow another process to begin execution, and when the process came 
back, return to exactly where it was left off.  This is what is known as 
program re-entrancy and is a veritable *nightmare* to program.  So, for
most programmers, the nightmare is avoided and the routine simply does a
brute force indexing -- hoping that nothing critical is going on in the
other processes.  Hoping that there's no communications, vital calculations,
important network transfers, nothing.  Because *nothing else can happen
until the indexing routine is finished!!*  PMT allows this to be avoided
entirely, with some PMT operating systems permitting a wide range of
priority settings on a wide range of priority classifications so that the
system can be fine tuned to what I would call "perfect."  For example, 
an FTP transfer can be given a slightly higher priority than WWW access
because FTP requires a continuous connection.  A communications program
would be given yet higher priority because it must process any incoming
data as quickly as possible -- while the rest of the system is comfortable
in the knowledge that 28.8k baud is only a fraction of the total bandwith
the computer is capable of.  In fact, this is one of the biggest flaws
I see with many systems, with the communications program requiring more
CPU time than necessary; and yet the networking protocols have got it
right even though the bandwidth with networking is 10x greater than 
any modem.  Try White Knight -- what a piece of junk.  Try Procomm for
Windows -- what a piece of junk.  Try HyperAccess (text) for OS/2, or
Zcomm for OS/2 -- now we're talking.  The CPU utilization for the OS/2
applications are 3% during full transfer speed.  Get that, three 
percent.  Look at the Windows or Mac options.  The utilization 
jumps from 100 percent to zero, and back to 100 averaging out to 
be greater than 50%!  

>I would imagine it is a distributed fault-tolerant transaction-based
>system; the kind that shows why it is hard to use PMT (you want
>transactions to be atomic, fast as possible, and fault-tolerant; not easy
>to get right).
>

True, and so one would used a dedicated controller.  Why would PMT be
needed?  IS THIS THE ONLY WAY FOR YOU TO SAY THAT PMT ISN'T THE PERFECT
SOLUTION FOR GENERAL DESKTOP COMPUTING?

>So, why don't you tell us *how* PMT is going to make our lives oh so much
>better, instead of emptily asserting it without proof or justification
>that it will.

I just did.  Granted the Macintosh programmers (and the operating system) 
are better suited to re-entrant programming, but I've never seen a mac work
as smoothly as any other PMT operating system.  Not even close.

>        Nevin ":-)" Liber       nevin@CS.Arizona.EDU    (520) 293-2799