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

[David Garfield]

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 |      |
        +--------+------+

> 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!

> 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.

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.

The real problem is YOU NEED BOTH!

> cheers,
>
> Peter
>

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.


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