Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-lcc!lll-winken!uunet!munnari!murtoa.cs.mu.oz.au!ditmela!latcs1!suter From: suter@latcs1.oz (David Suter) Newsgroups: comp.sys.transputer Subject: transputer scheduler Keywords: priority Message-ID: <5339@latcs1.oz> Date: 25 Mar 89 06:45:38 GMT Organization: Comp Sci, La Trobe Uni, Australia Lines: 35 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 4785814