Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!bsy
From: bsy+@cs.cmu.edu (Bennet Yee)
Newsgroups: comp.arch
Subject: Re: Ignorance speaks loudest (was:Computers for users not programmers)
Message-ID: <1991Feb6.175555.18281@cs.cmu.edu>
Date: 6 Feb 91 17:55:55 GMT
References: <1991Feb4.210853.22139@odin.corp.sgi.com> <1652@hpwala.wal.hp.com> <409@bria> <13252@lanl.gov> <1991Feb4.154607.8606@ux1.cso.uiuc.edu> <1991Feb5.020456.1119@ux1.cso.uiuc.edu>
Sender: netnews@cs.cmu.edu (USENET News Group Software)
Organization: Cranberry Melon, School of Cucumber Science
Lines: 57

In article <1991Feb5.020456.1119@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: (DM2)

>In article <1991Feb4.210853.22139@odin.corp.sgi.com>
archer@elysium.esd.sgi.com (Archer (Mr. Slug) Sully) writes: (AS)

>>In <1991Feb4.154607.8606@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu
(Doug McDonald) writes: (DM1)

DM1>.... The most general method  means that you call a system 
DM1>subroutine with a pointer parameter to a buffer, and a file descriptor of
DM1>some sort, and a size, and a function pointer to a "completion routine".
DM1>
DM1>YOUR PROGRAM CONTINUES RUNNING. IT DOES NOT BLOCK.

AS>I've implemented this in UNIX ..., it wasn't an 
AS>improvement over the normal file system.  Performance differences ranged 
AS>from a 1% gain to a 5% loss on real life code.  Generally we found that
AS>when accessing a file sequentially the kernel did a better job of figuring
AS>everything out than the program itself could.  ...

DM2>For general purpose sorts of computing that can normally be done on Unix
DM2>you are quite right indeed, these days. But for special cases - 
DM2>real time stuff - it can still make a big difference. The point is that
DM2>async IO wins when you simply CAN'T stop your computing (CPU use) to wait
DM2>for a disk transfer. OR when you try to get the absolute most performance
DM2>out of a machine running only ONE program (i.e. a Cray doing
DM2>a weather simulation.)

It seems to me that this computation model is not that good.  It's sort of
continuation style, but not really.

A better one, perhaps, is one where your task has two (or more) threads, of
which one can be CPU bound and the other handle your (slow) disk I/O,
blocking if nec'y.  It's more general, and the kernel does NOT have to
understand the calling conventions of your language implementation to invoke
the completion routine.

To emulate the style advocated by DM, the I/O thread is just created at the
call and terminated after it invokes the completion routine.

Another possible method would be more Unix-y, with signals to indicate I/O
completion.  Hardware jocks may like the signals more tho, cuz of the
analogy to interrupts.  The signal handler is your completion routine.  This
is inferior in that you need to either disambiguate or have a different
signal per outstanding I/O request.

[ Isn't this newsfroup supposed to be moderated or something?  Is SOFTWARE
architecture really appropriate?  Would the moderator care to comment?
Should this entire thread be moved to comp.unix, comp.os.research, or maybe
alt.religion.os.flame.war? ]

-bsy
--
Bennet S. Yee, +1 412 268-7571
School of Cucumber Science, Cranberry Melon, Pittsburgh, PA 15213-3890
Internet: bsy+@cs.cmu.edu		Uunet: ...!seismo!cs.cmu.edu!bsy+
Csnet: bsy+%cs.cmu.edu@relay.cs.net	Bitnet: bsy+%cs.cmu.edu@carnegie