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!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 17:35:05 GMT References: <1652@hpwala.wal.hp.com> <409@bria> <13252@lanl.gov> <1991Feb4.154607.8606@ux1.cso.uiuc.edu> <1991Feb4.210853.22139@odin.corp.sgi.com> <4032@stl.stc.co.uk> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 59 Nntp-Posting-Host: odin In-reply-to: tom@stl.stc.co.uk's message of 13 Feb 91 20:38:27 GMT On 13 Feb 91 20:38:27 GMT, tom@stl.stc.co.uk (Tom Thomson) said: tom> Here we have Archer Sully demonstrating yet again that the JGs and tom> Rubins of this world are absolutely correct when they claim the tom> "standard Unix or nothing" brigade have nothing to offer to us on tom> software architecture. Well, the usual ones don't; but Mach for example has something to offer, even if it is not Unix (just like most decent Unix implementations for modern machines, it emulates Unix quite closely). tom> Mr Sully wants to put synchronous IO in my way, ie conceal from me tom> the fact that the hardware allows IO and processing to procede in tom> parallel; he claims that with today's discs it isn't needed. This is 80% true, i.e. billjoysm. It is a true that the optimal multiprogramming level is N+M, where N is the number of CPUs and M is the maximum number of concurrent IO operations, and that on common timeshared machines N+M is rarely larger than 4, so that even a small degree of timesharing will achieve optimal *overall* thruput. tom> I suggest he goes and tells that to all the independent database tom> vendors who spend so much effort in getting round this particular tom> piece of Unix stupidity in their Unix ports. But database people have a very particular problem: their databases are, in effect, OSes in their own right, and have their own scheduler, disk access subsystem, and so. The problem they have is that the virtual machine or process in which they run gets blocked by the underlying OS in its entirety, because the underlying OS has no notion of the fact that it is running multiple database threads. This happens for IO, but also for paging, and signaling, and so on. Why do database choose to reimplement almost all the facilities of an OS in the batabase server? For *portability*. tom> Perhaps he can afford for the machine to sit idle for 10 ms every tom> time he moves the disc heads - he maybe has never been involved in tom> a time-critical or performance-critical application. But during that time another Unix process will be scheduled, and overall system thrupu will not be impacted. Note that Unix IO *is* asynchronous, as seen by UNIX systems. The problem that people have is that it is not asynchronous with respect to one of the threads inside a database server. But this is a problem with *both* the database server *and* Unix; the problem with database servers is that they are implemented as monolithic OS reimplementations, and the problem with Unix is that it does not make it efficient or easy to have database servers implemented any other way. Since Unix is not the only operating system around that supports only the monolithic program model, *portability* demands that vendors that want to port their server to a variety of platforms assume it as minimum common denominator. Too bad. -- 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