suter@latcs1.oz (David Suter) (03/25/89)
I have found little information about the implementation of concurrent processes
on a single transputer. At the hardware level the Transputer Ref. Manual makes
the point that the microcoded scheduler itself does not consume time
as inactive (read for i/o or suspended for a specified time) processes do not
consume processor time. They are, it seems, suspended
and placed on the active list only when an autonomous link interface (for i/o
- for timer in case of specified time?) cuases them to be rescheduled.
A process is executed until it requests i/o or awaiting the timer.
This seems fine, however there is little information about how the OCCAM
compiler maps its concurrent processes onto this. There is a brief statement
about PRIoritised processes - but what about equal priority processes. Does
the current implementation(s) of OCCAM time slice the equal priority
proceses (if so at what rate) or does it follow the above hardware model for
efficiency where
PAR
process1
process2
will actually run either as SEQ process1,process2 or visa versa
if neither requires i/o.
It seems hard to reason about efficiency of code without this info - can anyone
point me to a detailed account of this.
Also - what about the various C compilers - do any of them support
multiprocessing on a single transputer - if so how?
---------------------
David Suter ISD: +61 3 479-2393
Department of Computer Science, STD: (03) 479-2393
La Trobe University, ACSnet: suter@latcs1.oz
Bundoora, CSnet: suter@latcs1.oz
Victoria, 3083, ARPA: suter%latcs1.oz@uunet.uu.net
Australia UUCP: ...!uunet!munnari!latcs1.oz!suter
TELEX: AA33143
FAX: 03 4785814WHITCOMB%KOBOT@VENUS.YCC.YALE.EDU ("whitcomb%kobot.decnet@venus.ycc.yale.edu") (04/01/89)
Greetings:
The T-800 support for scheduling and concurrency is described succinctly
on pages 52-53 of the first listed reference.
The essential facts are the following:
(1) High priority processes run until they either terminate or block
themselves. First come, first serve. High priority processes
are *not* timesliced.
(2) Low priority processes run only when no high priority processes are
available to run.
(3) Low priority process run until they terminate, block themselves, or
until they have run for one to two *timeslice periods*.
(4) A *timeslice period* is 5120 cycles of the external clock. This is
about one mS at 5MHz.
(5) Given n low priority processes, the maximum time a process will wait
on the process queue for cpu time is 2n-2 timeslice periods.
The manual gives a complete account, defining which actions will cause a
process to block, exactly how the queues are handled, and the like.
You note seems to suggest that there is a lack of documentation on this
topic. This is not so. If one wants understand how the machine works,
and how the INMOS implementation of OCCAM is constructed, you absolutely
must have the following references:
Transputer Reference Manual
ISBN 0-13-929001-X
Transputer Technical Notes
ISBN 0-13-929126-1
Communicating Process Architecture
ISBN0-13-629320-4
Transputer Instruction Set
ISBN 0-13-929100-8
It is all there. In excrucuating detail.
The Best,
-Louis Whitcombcs395t54@cs.utexas.edu (Pow Hwee Tan) (04/02/89)
About whether running a segment of code like
PAR
p1
p2
will run sequentially or parallel on a SINGLE transputer, my experience
tells me that the transputer did do a time slice scheduling. This
is because if the above code were to run on a single transputer then
it will run slower than a sequential one, ie:
SEQ
p1
p2
The slower performance is due to task switching.
pow-hwee tan
--
tph@minnie.cc.utexas.edu