Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Apple HD SC 80 does not support Asynch i/o.
Keywords: Just what is the problem here?
Message-ID: <11614@dartvax.Dartmouth.EDU>
Date: 3 Jan 89 20:26:06 GMT
References: <11605@dartvax.Dartmouth.EDU> <271@berlin.acss.umn.edu>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 50

In article <271@berlin.acss.umn.edu> grg@berlin.acss.umn.edu (George Gonzalez) writes:
>
>Asynchronous I/O is a wonderful idea if you have a true pre-emptive multi-
>tasking system.  The system can start an I/O request, and run another task
>while waiting for the I/O to complete.  This means tasks get more CPU time;
>less time is spent waiting for I/O.  If its done right, the tasks need not know
>or worry about the I/O being done asyncronously.  Just wonderful.

I believe you are missing the point here.  There are many cases where
a user is interested in ONE task coming to completion as fast as
possible, and where that task involves both significant I/O and
significant computation.  An example might be a multi-dimensional
disk-based FFT.  If things run only the way you describe, the FFT
program gets swapped out every time it accesses the disk, and other,
less important, tasks get use of the machine.  The important task
might even lose several time-slices if the I/O takes a while.  It
could have used these for significant computation if only the
programmer had considered use of asynch I/O and the system had
supported it.  This is why VMS, a multi-tasking system, allows a
programmer to specifically request asynchronous I/O instead of the
other kind.

This applies whether or not the operating system supports pre-emptive
or any other kind of multi-tasking.  If you, the programmer, are
limited to synchronous I/O then you simply are not capable of
providing the performance you could, were you allowed to use asynch
I/O.  This can be the case, even in a pre-emptive multi-tasking
system, if a task has to give up control while it waits for I/O.

The Mac OS supports asynchronous I/O for all drivers installed in the
system.  Inside Macintosh gives quite precise instructions for an
application developer to use it.  There can only be one of two reasons
why this feature is not implemented for SCSI hard disks, even the
Apple HD SC 80:

	a)  Disk driver writers were too lazy to put it in, and
	    figured most people wouldn't miss it.

	b)  The present SCSI interface is not capable of it.  I don't
	    know how this could be true, but I am extremely unwilling
	    to believe that the Apple drive cannot do asynch I/O because
	    of the first reason.

Anybody have any idea which of the above is true?  I've started to
wonder, since the Apple HD SC 80 failed Oster's Asynch test program
last night.

Earle R. Horton. 23 Fletcher Circle, Hanover, NH 03755
(603) 643-4109
Graduate student.