Re: waking up processes on external input

["P.H.Welch" <P.H.Welch@xxxxxxxxxx>]

Hi Richard,

> My current understanding is that on the transputer, processes were
> not members of the process queue when they were waiting for input
> from the external links. This would mean that whenever input arrived,
> some mechanism would have to add to the queue any process waiting
> on the link.

> Was this mechanism was part of the hardware, or was it done with
> a software interrupt handler?

Processes are on the "process queue" - i.e. the "run-queue" - unless
they are blocked waiting for some kind of synchronisation (on the
transputer and classical occam, this was channel communication and
timeouts).  Processes waiting for input on *any* channel (hard or
soft) are not on the run-queue - a reference to them is in the
channel word.  Same for processes waiting for an output to be taken.
Processes waiting on a timeout are in a timeout-ordered list.
(occam-pi has other sync mechanisms - barriers etc. - and all
follow the same principles.)

For soft channels, the process completing the communication triggers
microcode in the transputer (or the KRoC run-time kernel) to add
the waiting process to the back of the run-queue.

For hard channels, the transputer link holding the channel on which
the process is waiting synchronises with the main processor to add
the process safely to the run-queue.  No software interrupt handler!
For KRoc/pony/RMoX, something similar happens (will happen) ... but
uses software (in the absence of transputer-like hardware).

Expiring timeouts in the transputer triggered hardware also to
synchronise with the processor to safely add processes back on
the run-queue.

As Barry said, it is the close integration between the communication
link hardware with the main processor - and their otherwise completely
parallel operation - that is the key to low latency external
communications and overlapped comms-and-compute.  The transputer's
capability here (at 20 MHz) still outperforms today's systems.

No modern architecture has anything resembling this ... with bad
consequences for fast reacting embedded systems and supercomputers.

Let's hope David May's new XMOS venture will succeed and restore
some elegance to these things ... but I've no idea what he's going
to be doing ... even if he's going to aiming at parallel things?

Peter.