Bulletin number:  7
Products affected: Z999
Description: Feature of the Transputer
Component: 
Date: Fri Feb 2 16:36:13 GMT 1990
-----

The following information is an edited version of a memo from Roger
Shepherd.  The information should be passed on to anyone working in
the operating systems type area.  It should not affect most people.

----------------------------------------------------------------------

I was phoned by a customer because he thought he was getting funny
behaviour from a T800.  I spent some time looking at the problem and
it turns out that the transputer does not behave as one might expect.
The exact nature of this "feature" is explained below.  Although the
customer was using the part in an undocumented manner I feel that what
they were trying to do was reasonable; I also suspect that other of
our customers may (or may have) run into the same problem.

Nature of the problem

Consider the following process:

ALT
  c ? ...
    P
  TIME ? AFTER ...
    Q

If the channel c comes ready before the timer input, the process will
be scheduled.  Subsequently, either the timer will be disabled or the
timer will become ready.  If the timer comes ready nothing will happen
as there is an interlock mechanism which prevents the process being
scheduled twice.  This mechanism works correctly whether the process
is currently executing process or is on the scheduling queue; indeed
the timer has no knowledge of whether the process is executing or not.

This being so, it seems reasonable that the process could safely be
removed (by explicit manipulation of the pointers) from the scheduling
queue; one would assume that the interlock mechanism should continue
to work.  However, it turns out that if the process is removed AND the
processor becomes idle AND the timer becomes ready the transputer goes
haywire!  The reason for this is that the microcode assumes that when
a timer comes ready but does not schedule a process then there MUST be
a current process and causes the next instruction of that process to
be executed.  In our case there is no current process and so making
the processor execute the next instruction of that process causes a
problem.  Note that when used normally the microcode's assumption is
correct; the only reason that a scheduling does not take place is that
the process that would be scheduled has already been scheduled; that
process is, therefore, eitherthe current process or in on the queue.
If it is on the queue then there must be some other process.

I have just realised that the same problem will occur if a link is
used instead of the timer.

----------------------------------------------------------------------

Since that memo was written it has been decided to call this a
feature.  The potential fixes have too many side effects..