Two Kernels: Sync/Async [pem01] [djg26]

[Peter Mueller]

> From davgar!davgar.arlington.va.us!david@uunet.UU.NET Tue May 25 07:11:02 1993
> Date:      Tue, 25 May 1993 00:58:04 EDT
> From: "David Garfield" <david@davgar.arlington.va.us>
> Organization: Third Star on the Left
> To: moose-programmers@sfu.ca
> Subject:   Re: Two Kernels: Sync/Async [pem01] [djg26]
> Content-Length: 3159
> 
> Peter Mueller wrote:
> > Hi,
> >
> > it seems, that I've a big communication problem :-)
> > Here I go again:
> >
> > What I want is this:
> >
> >         +-------+----+
> >         | BLACK |    |
> >         +-------|    |
> >         | KERNEL     |
> >         +------------+
> 
> Actually, it is probably more like:
> 
>         +---------------+
>         | BLACK BOX     |
>         +--------+      |
>         | KERNEL |      |
>         +--------+------+
> 

Well, I don't want to start kind of hick-hack how it will look like. I think
that will bring us no step further. Let's do agree that there's a black box.


> > The black box should be the communication stuff. It is
> > an object, providing an interface to IPC primitives
> > such as
> >         send, receive, reply
> 
> Again, I think you have the wrong basic model.  There is (or should
> be) no such call as "receive".  ("reply" is questionable, but that
> discussion comes later.)
> 
> > I want to change this black box to be either sync or
> > async. All other kernel stuff should remain the same.
> > Thus we actually have only ONE KERNEL box.
> 
> One kernel box, but the basic devices (outside the kernel) are easily
> 10 times the size, probably more like 100 times.  And for them, THE
> COMMUNICATIONS MODEL IS CRITICAL!

Stop it! Didn't I have said that I don't want to implement the whole
os in two versions? I only want the possibility to make a sync. kernel. That
require the possibility to change the black box. Ok? AND IF YOU STILL THINK
THAT I WANT TWO WHOLE OS I CAN'T HELP YOU. BTW: Most modern OS uses sync.
IPC within their kernels. eg. PEACE, QNX, ... 

> 
> > Then: We have to come to an agreement, which BLACK box
> > we choose in our first release. (You already know what
> > I want, do you :-) Then ALL apps are designed to use
> > this specific BLACK box, hence, using these IPC
> > primitives.
> >
> > I only want to state the following: It should be possible
> > to make a design suggestion, where the IPC is a black box
> > which is exchangeable. (And if you all want async IPC
> > then I will follow you until I have my own system, where
> > I then will change to the sync. kernel.)
> >
> > That's all. Please don't get confused for the term
> > 'two kernels'. I still think we should implement a
> > 'homogeneous' system.
> 
> Synchronous can be done trivially on top of asynchronous.
> Asynchronous on top of synchronous requires a helper thread and lots
> of pain.

No. Sorry, I do not agree. Async. IPC will force a performance lost for 
some apps, which can be easily handled with sync. IPC. On the other hand
if async. is built with lightweight (AND THAT AREN'T PROCESSES, WHICH
ENABLING CAUSES PLENTY OF TIME) threads, there should be a minimal performance
lost for async apps. If you do it the other way round, the performance lost
for sync. apps. will be much much more greater.

> 
> With a properly implemented system on top of an asynchronous setup,
> you will NOT be able to replace it with a synchronous setup.  :-)
> With a properly implemented system on top of a synchronous setup, you
> WILL be able to replace it with an asynchronous setup.  :-)  Sorry.
> 
> > I do agree that it is possible to simulate each IPC
> > form with the other, though I believe simulating sync
> > IPC out of async IPC is like using a steam hammer to
> > crack a nut ... but that's IMHO ... ;-)
> 
> Sync from async is using a steam hammer to crack a nut.
> Async from sync is using a nutcracker to crack pavement.

Again: NO! Why are modern os using sync. IPC, then?

> 
> The real problem is YOU NEED BOTH!
> 
> > cheers,
> >
> > Peter
> >
> 

FIRST OF ALL: UNIX IS *NO* MODERN OS. IT IS HEAVY, UNFLEXIBLE, LIKE A
DINOSAUR, AND SHOULD BE REPLACED BY ANOTHER SYSTEM. UNIX is a monolithic
OS, where all things, which are to be said to be included in a 'modern'
os are fixed within the kernel. This leads to a tremendeous overhead in all
os related stuff. So, I do agree, that your example is a counterexample IF
YOU COMPARE UNIX AS A MODERN SYSTEM. Sorry, I don't think that this 
comparism is useful.

> All right, try this:  under Unix, write a program that reads data from
> two data sources and does different things with the data, such that:
>         1) only one process is used
>         2) select() is not used
>         3) either data source can produce data that will be processed
>            imeadiately (sp?)
>         4) the program does not eat CPU time
> 
> If you can do this in Unix, I want to see it.  I don't think Unix,
> which only has synchronous IO, can do it.
> 
> With VMS and its asyncronous IO, this is trivial.

VMS is ALSO NOT A MODERN SYSTEM. Stop talking about the old world, think over
the new one and look into future ... In current OS research there is the trend
to ask, what must not be in the kernel and not what do I want to have in it.
Eg. The QNX micro-kernel provides the following four (4!) functions:

	1) Synchronous IPC (send, receive, reply)
	2) Process scheduling (ie. context switch)
	3) Network connection
	4) Interrupt/Signal-handling (a signal is simply converted into
           a message which is then transferred to an appropriate server, which
           resides outside the kernel.)

The latter two points are placed within the smallest units. Sometimes if you
ask, what should the kernel of a modern OS provide, you will hear:

	1) Synchronous IPC (because it must be fast)
	2) Process execution (ie. scheduling)

 
> 
> David
> -- 
> David Garfield/2250 Clarendon Blvd/Arlington, VA 22201   (703)522-9416
> Email: david%davgar@uunet.uu.net or garfield@verdi.sra.com
>

cheers, 

Peter