Asynchronous I/O under UNIX

Martin Weitzel martin at mwtech.UUCP
Thu Dec 21 00:04:33 AEST 1989


In article <932 at crash.cts.com> peterson at crash.cts.com (John C. Peterson) writes:
>
>I am developing a code to LU factor large symmetric matrices on an FPS
>522 ( running BSD 4.3 ) which are too large to fit in RAM memory. The
>mechanics of "out of core" algorithms are pretty straight forward, but
>to be efficient, the I/O should be done asynchronously. There seems to
>be no real painless way to do this under UNIX.
[rest deleted]

By it's pure nature I/O to disk under UNIX is often more 'asynchronous'
than it appears to be:
- A write system call returns, if the blocks have been placed in
  the disk cache (Rochkind's book "Advanced UNIX Programming" has
  a very nice little section about this on page 29 - read and
  enjoy). The physical I/O may well overlap with CPU-activity.
- A read system call starts some machinery in the kernel which
  tries to decide, if sequential reads are made and if this seems
  to be true, carries out 'read ahead's, which often yields in the
  same effects, as asynchronous reads.

Of course, sometimes a progam can decide more efficiently than
the kernel, especially if reads are not done sequentially, but
it often seems, that UNIX programmers want to take too much
responsibility for efficient I/O. (This is more a general remark
than a criticism of the ideas of the poster).

KEEP IN MIND: These are not any longer the days of 'single job
batch processing' where it was on the programmers responsibility
to keep the cpu and the disk equally loaded. The UNIX kernel
does quite a well job in this respect - may be not allways the
best but far better than many programmers think!
-- 
Martin Weitzel, email: martin at mwtech.UUCP, voice: 49-(0)6151-6 56 83



More information about the Comp.unix.wizards mailing list