From: timbol@cory.Berkeley.EDU (Mike Timbol)
Subject: Re: Benefits of OS/2?  
Organization: University of California, at Berkeley
Distribution: na
Date: Mon, 13 Apr 1992 13:00:28 GMT



chawdry@dorothy.cis.ohio-state.edu (rehan nisar chawdry) writes:

>In article <4107@sumax.seattleu.edu> khamer@sumax.seattleu.edu (Little Kenny Hamer) writes:
=>
=>
=>Item 2: Mutitasking
=>
=>      This does seem to be the battle cry these days.  Sorry, I must be a 
=>neanderthal, but I do not really multitask.  Nor does anyone I have ever seen
=>(at least on a personal computer...  ).  People keep multiple apps open at
=>a time, but few actually *use* tham at the same time.  By way of example:
=>

>Well, I'll comment on one aspect of your post and that is the multitasking
>part.  Your understanding of multitasking is a little superficial in view (no
>flame intended).  From what I understand, you're thinking that one person 
>cannot use more than one app at a time -- I'll agree with you completely.  In
>this sense multitasking is only beneficial for the user that performs
>downloads, formats disks, and then REALLY works on one specific app, say
>a word processor.
>

This part I agree with.  This is stuff that takes lots of real 
time, but little CPU time, so multitasking works well (you get 
to use the CPU when it would otherwise be idle).

>
>What OS/2 implements, though, is a much more elegant form of multitasking
>called multithreading.  Multitasking relies on the user calling up two or
>more apps *HIMSELF* and letting them run their merry way.  Of course you can't
>expect the user to *USE* both at once -- how can the mouse cursor by in two
>places at one time, how can typing come to two windows at the same time, etc.
>This is what you might be used to with Windows, Desqview, Geoworks, etc.
>
>Multithreading, however, relies on the *COMPUTER* calling up several apps and
>*INSTRUCTING* them to perform a specific task simultaneosly.  In Windows, if
>you issue a print command, you have to wait for your app to process a page, and
>wait some more while the data is transferred to Print Manager.  Then, printing
>goes on in the backround.  While all this is happening, you can't do *ANYTHING*
>.  

Once the Print Manager is controlling the printing, you *can* 
do things (at least, from what I recall).  I believe that you're 
correct, though, that you get the hourglass icon (in Windows) while the 
data is being transferred.

>
>In OS/2, if you issue a print command, the cursor is returned *IMMEDIATELY*.
>The app will call a program that runs in the backround and instructs it to
>start printing page 1.  The app may then call another instance of that same
>program and instruct it to start printing page 2 *AT THE SAME TIME*.  That 
>app can call as many instances of that printing module and all of it happens
>in the backround.  

I don't see how this can possibly work (unless you have two 
identical printers and a really strange driver for this).  
suppose that (for apps that do this) you could simultaneously 
build the bitmaps that are sent to the printer, then send them 
one at a time.  But then you'd have to keep the second bitmap
in memory while the first was printing.

>Meanwhile, while you have control of the cursor, you may
>want to open 4 files in a word processor to compare them.  Issue 4 open
>commands within 10 seconds and your word processor will call 4 "open" modules
>that each begin to load the data files.  So, there would be 8 programs
>running simulataneously -- 4 "open file" programs and 4 "print file" programs.

I don't think this is an advantage at all.  If the four files were 
all on the same hard disk this would be far worse because of the 
added seek time jumping back and forth between the files you 
wanted to open.  (Now, if you had a properly configured RAID 
setup...)

>While each is running, you the user still have control over the mouse and
>any input you give.  And looking at the big picture, you the user are still
>only using one app.  It's just that that app is running several programs
>in the backround.  That's multithreading and that's why apps specifically
>designed for OS/2 2.0 will handily run circles around Windows apps (in
>performance, I mean, not necessarily functionality.  That will change of
>course when Ami Pro is *WRITTEN* not *PORTED* for OS/2).
>
>        -- Rehan --

Overall, I agree that multitasking/multithreading is a good 
thing, but not in every case.  Multitasking two or more disk
access (to the same disk) would (I think) degrade performance over 
doing this sequentially.  Also, running a spelling check on one
document while working on another (another popular example)
doesn't seem to be of much use (at least for me; I usually 
make enough spelling mistakes to prevent this from being a 
background task :).

A single multithreaded application only has a performance increase
during periods when the CPU is waiting for something to happen.
An OS/2 word processor would be better than a Windows word processor
only because of 32-bit code or while waiting for a file to open or
save.  Something that takes actual CPU time under Windows will
still take CPU time under OS/2..

Anyway, I'm just a CS student, so please feel free to correct 
me if I'm wrong.

                                      - Mike
                                        (timbol@cory.berkeley.edu)