Newsgroups: comp.sys.transputer
From: traff@diku.dk (Jesper Larsson Traff)
Subject: The "buffer-copying problem" in OCCAM and CSP
Organization: Department of Computer Science, U of Copenhagen
Date: Wed, 6 Apr 1994 17:13:15 GMT
Message-ID: <1994Apr6.171315.20804@odin.diku.dk>


*The buffer-copying problem*

Here is what I think is a general problem in OCCAM and CSP - at least
I haven't found an elegant solution. Comments anyone?

Assume we have a process P that generates some data, 1 item at a time,
that have to be lumped together and sent to another process (in this
case, running on another transputer). We want P not to become blocked by the
sending. Hence, just sending from P is not satisfactory. Instead, a
buffer process Q, running in parallel with P, should be made
responsible for the sending.

Unfortunately, one buffer process is not enough. If Q receives data
items from P into a local buffer, the moment the buffer is full, Q
will have to start sending, and at this point will be unable to
receive further data from P. So, one more process R is needed, which
accepts a lump of data from Q, sends it off, and sends an
acknowledgement back to Q. Q only attempts to send data to R when it
knows that R is ready (ie. after receiving the acknowledgement), and Q
will then be unable to accept data from P only for the time it takes
to transmit (internally) one lump of data from Q to R.

This is all good and fine - but from a programmers point of view there
are two annoying but's. The first is that if the buffers cannot be
dimensioned very accurately, a lot of space is taken up by having 2
processes apart from P each with its own large buffer. The second -
and most annoying - problem is that a lot of expensive, internal
copying has to take place: P->Q->R -> to receiving process. The
principle of memory-disjointness makes it impossible to share the
buffers and simply pass pointers among the processes. The problem seems to
be inherent in CSP/OCCAM - but maybe I've overlooked a simple solution
(putting a -a or -n option on the when compiling does not count).


Jesper Larsson Traff, DIKU, Copenhagen, Denmark


