[e-lang] Missing (?) E concurrency mechanism

Jonathan S. Shapiro shap at eros-os.org
Sun Nov 28 14:48:07 EST 2004


On Sun, 2004-11-28 at 14:05 -0500, Mark Miller wrote:

> > In my opinion, the one interesting concurrency mechanism that E lacks is
> > an event queue that is shared across multiple co-equal vats. This is
> > exactly the same problem that KeyKOS/EROS have in the current
> > call/return design.
> 
> I don't understand.

Let me try this by analogy. I'm not sure if it will hold up in the
context of E.

One (in hindsight significant) flaw in the KeyKOS/EROS design is that
messages are addressed to processes, not to message queues. In E, I
believe the analogous thing would be to say that messages are addressed
to vats.

In the vast majority of cases, this is a fine model, but in cases where
concurrent handling of requests is desired, this model unifies two
things that ought properly to be separated: the message rendezvous queue
and the thread of control that receives the message.

In Coyotos (the EROS successor), we are moving to a model where the
message queue is ``first class''. Sender sends a message to a queue,
receiver(s) receive on it. No buffering, so efficiency is as before.
What this buys us is the ability to do thread dispatch within the
kernel, which avoids copies and can leverage scheduling information that
is not available to the application (such as CPU affinity knowledge).

When an extended session with some particular client is required, an
Coyotos process can fabricate a per-session receive queue, provide that
capability to the client, and receive on that until the session is done.

In the context of E, the analogy would be to say that multiple serving
vats can arrange to receive on a shared queue. Each vat gets a single
message off of this queue. If an extended session is required, a
separate receive queue can be established for the duration of the
session.

I'm not aware of anything in the Vat model that would prevent a vat
thread from *voluntarily* receiving on an alternative receive queue.
There is a determinism issue, but I do not think that it is
insurmountable.

shap
-- 
Jonathan S. Shapiro <shap at eros-os.org>



More information about the e-lang mailing list