Asynchronous output

[Griff Smith]

In article <1858 at batcomputer.tn.cornell.edu>, garry at batcomputer.UUCP writes:
> I have an application which entails computing and churning out vast
> quantities of data and, for speed, I'd like to have the I/O happening
> in parallel with the computing. After reading the BSD and SysV manuals, 
> I'm puzzled: does the system give us *any way* to do asynchronous output?
> 
> I've thought of writing a (presumably buffered) pipe to "cat" and thence to
> my device. Is there anything else?
> 
> garry wiegand   (garry%cadif-oak at cu-arpa.cs.cornell.edu)

It depends on who else is using the computer, where you are putting
your data, etc.  If you are writing to a disk file, don't worry; the
disk system is buffered internally.  If you are writing to a mag tape
and you are the only one on the system, you might want to fork a tape
writing process.  If you are using System V, you could even use shared
memory to pass data to the process without writing or copying it.  If
shared memory isn't available, try a pipe.  Remember, though, that
pipes aren't free.  The time it takes for one process to write the pipe
and another to read it may be larger than the time spend waiting for
the tape to spin.  If the system is heavily loaded, complicated
multi-process buffering schemes may slow you down; the system will just
run something simpler instead.  Your best strategy is usually to
minimize your own cpu requirements so you make the best use of the
fraction of the cpu allocated to you.

Of course, if you have the machine to yourself the only thing that
matters is elapsed time, not cpu time.  In that case, you might
consider running something else useful to soak up the idle time.  You
still won't get the primary job done any faster, but the total
productivity of the system should improve.

After an experience I had about 7 years ago I am not very enthusiastic
about asynchronous I/O in time-sharing systems.  We were using TOPS-10,
which had a buffering scheme for asynchronous I/O.  After having many
problems in the kernel caused by cache maintenance errors during
asynchronous I/O, we defeated the asynchronous feature.  The system
itself was still highly asynchronous, but not within processes.  Users
didn't know the difference but the system did: improved system
stability, better system throughput, faster disk performance, less disk
fragmentation.