Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!bonnie.concordia.ca!ccu.umanitoba.ca!herald.usask.ca!alberta!ubc-cs!uw-beaver!mit-eddie!wuarchive!zaphod.mps.ohio-state.edu!samsung!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: Ignorance speaks loudest (was:Computers for users not programmers) Message-ID: Date: 14 Feb 91 18:13:25 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> <3177@crdos1.crd.ge.COM> <4033@stl.stc.co.uk> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 68 Nntp-Posting-Host: odin In-reply-to: news@stl.stc.co.uk's message of 13 Feb 91 21:16:38 GMT On 13 Feb 91 21:16:38 GMT, news@stl.stc.co.uk (News admin c/o dww) said: news> In article <3177@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com news> (bill davidsen) writes: davidsen> UNIX writes usually overlap CPU, since the system buffers davidsen> them. Async makes little difference in run time for an i/o davidsen> bound job or a CPU bound job, it's only in the case where i/o davidsen> and CPU time are roughly equal that a major improvement is davidsen> seen. True, but only true for the 80% of cases where you have a sufficiently high multiprogramming level at the Unix process level. news> Might as well point out the several problems with this: news> (i) buffering writes in the OS means I don't know when a transfer news> has terminated. This is an easily remedied deficiency. It has been remedied, with things like fsync(2). Badly, let me add, but it has been remedied. news> (ii) buffering writes in the OS means an extra copy. Another easily remedied deficiency. Virtual memory helps a lot here. news> (iii) Async io can make enormous differences in run time for io news> bound jobs - bd's conventional "wisdom" is an example of the news> rubbish that so-called software architects have foisted off on an news> unsuspecting world as knowledge. It's simple, really: if I am news> reading from 5 different discs, I can overlap the seek times, news> search times, and even channel times if they are split over two or news> more channels. This can be easily achieved under Unix if you arrange your application as five separate processes. Unix will overlap IO from different processes. I readily concede that this may be abominably complicated and inefficient in most current implementations. But the right solution is not to add asynchronous IO to a single process, it is to make splitting an application into multiple processes easy and efficient. This means that what (most) software architects have foisted upon you is not the lack of async IO, which is a poor hack in response to a bogosity; it is the lack of suitable OS level abstractions, and o efficient implementations of these. The specific bogosity is the lack of multithreading, and this is one of the consequences of having a monolithic program/process model, straight out of the sixties (early sixties, because in the late sixties there was Multics, at least). Adding asynchronous IO just perpetuates this ancient and inappropriate architecture. All your concerns are resolved, in the right way, without the complications and insecurities of asynchronous IO, if you can have proper multithreading, especially with threads that can move among address spaces, and lightweight and persistent address spaces. Second best is proper multithreading with efficient lightweight IPC among address spaces. Architecture is all about providing minimal and orthogonal abstractions, so that you get decomposability and reusability, and thus efficient and flexible system. Monolithic programs/processes, whether connected by (inefficient) glue like pipes or sockets, or "enriched" with ad hoc extensions ike asynchronous IO, are a poor abstraction. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk