Meyer, OO and concurrency

[David Hopwood]

Joe Armstrong (AL/EAB) wrote:
> Now the pipe mechanism was apparently (and I don't know if this was true)
> first suggest by C.A.R.Hoare

<http://cm.bell-labs.com/cm/cs/who/dmr/hist.html#pipes> says that it was suggested
by Doug McIlroy in 1972.

<http://www.princeton.edu/~hos/mike/transcripts/mcilroy.htm>:

   MSM: Where did the idea [for Unix pipes] come from?

   McIlroy: Goes way back. There was ... in the early sixties, Conway wrote an
   article about co-routines. '63, perhaps, in the CACM. I had been doing macros,
   starting back in '59 or '60. And, if you think about macros, they mainly involve
   switching data streams. You're taking in your ... you're taking input, you
   suddenly come to a macro call, and that says, "Stop taking input from here, go
   take it from the definition." In the middle of the definition, you'll find
   another macro call. So, macros... even as early as '64, ah, somewhere I talked
   of a macro processor as a switchyard for data streams. Also, in '64, there's a
   paper that's hanging on Brian's wall, still. He dredged out somewhere, where I
   talked about screwing together streams like garden hoses. [...]

Robin Milner's CCS, from which CSP was mainly derived, was developed from about
1973 on (see <http://www.win.tue.nl/fm/0402history.pdf>). Hoare's first paper on
CSP was published as a tech report in 1976, and in CACM in 1978
(http://portal.acm.org/citation.cfm?id=359585). So these were too late to have
been an influence on the design of pipes in Unix.

> Hoare's structuring principles correspond closely to Erlangs' mechanisms -
> with one significant difference - In Erlang messages are asynchronous, in
> Hoare's system synchronous. (Actually not a problem since synchronous
> message passing can easily be layered on top of an asynchronous system)

In a non-distributed system yes. In a distributed system it's much more
difficult (impossible with exactly the CSP semantics) to implement
synchronous message passing given the possibility of network partition and
process failure.

-- 
David Hopwood <david.nospam.hopwood@REDACTED>