roger@inmos.co.uk (Roger Shepherd) (02/26/90)
Subject: Semantics of In and Out instructions for memory channels? Dan McCabe <mccabe%unc.uucp%thorin@mcnc.org> writes to this mailing list: > Does anyone out in Netland know details about the semantics of the In and Out > instructions when a memory channel is specified? > I know that a channel is initialized with NotProcess.p (-1). I presume > that a process descriptor is kept in the channel variable. Is the > channel a linked list of waiting processes? No. It is either the process descriptor or it is NotProcess. > It seems to me that this would > have to be the case, since several processes may Out to the same channel before > another process does an In. No. Only 1 process may Out. Channels are 1-1 and implement synchronised communication. The (only) process which is outputting will be dscheduled when it performs its output if no process has yet performed an input. No further output can occur because the only process which is using the channel for output is descheduled. When the matching input occurs the outputting process is rescheduled. > Are the registers saved in the workspace if the instruction blocks > (when Out executes and there is no pending In or vice versa)? The only values in registers when an input or output instrcution is executed are the channel id, data pointer and message count. The pointer is saved into the workspace as is the instruction pointer. Nothing else is saved. > If you > treat the list of processes as a queue, you also need a tail ptr for > efficient insertion (as is the case for general process scheduling). True. There is a back pointer for the scheduling queue; there are no process queues for channels. > Is there some encoding that says that the channel is waiting either for > an In instruction or for and Out instruction? No. It is up to the user to ensure the channels are used correctly. When a suitable programming language (eg occam) is used this can be (and is) be done by a compiler. There is a good discussion of this in ``Communicating process architecture'', published by Prentice-Hall international, ISBN 0-13-629320. Chapter 2, The transputer implementation of occam describes the implementation and gives a rationale for the communication model. ``... commonication is point-to-point, synchronused and unbuffered. As a result, a channel needs no process queue, no message queue and no message buffer.'' Roger Shepherd, INMOS Ltd JANET: roger@uk.co.inmos 1000 Aztec West UUCP: ukc!inmos!roger or uunet!inmos-c!roger Almondsbury INTERNET: roger@inmos.com +44 454 616616 ROW: roger@inmos.com OR roger@inmos.co.uk