[coyotos-dev] Need for asynchrony

[Jonathan S. Shapiro]

On Wed, 2006-02-01 at 20:46 -0800, Charles Landau wrote:

> Concurrency is difficult to manage, but so is asynchrony. None of the
> above actually requires asynchrony (delivering a message, or
> notification, via an interrupt-like mechanism).

How do you propose that interrupt-like delivery (guaranteed prompt,
idempotent, one bit of state, preemptive) should be *efficiently*
implemented? One sender system call, please -- we wouldn't be using such
an unfortunate message type of the sender had any time to spare.

Interrupt-like delivery is *intrinsically* asynchronous. Receiver notice
of interrupt arrival requires a change of PC/SP. The term of art for
this when done at user level is "scheduler activation". It is probably
better to call them "activations". The "scheduler" part crept in because
of the particular application that led to the research.

> If the time and space required for kernel threads are large, are they
> any less for user threads?

First, it is not clear that user threads are actually required. Many of
the notify patterns only require that the receiver set a single bit
somewhere and continue main-path processing. Second, the user threads
can be much more effectively tuned to the needs of the application and
do not place pressure on kernel data structures.

>  So far I haven't seen a good motivation for asynchrony.

I look forward to a solution to the interrupt delivery problem.


shap