11

In the book about Communicating Sequential Processes a lot of time is spent defining events, which have no direction and can involve multiple independent processes.

Only in chapter 4 are channels introduced, which are directed and involve 2 processes.

Yet all implementations of CSP including occam, Go, LuaCSP and clojure.core.async only implement channels.

Even though most practical problems can be solved with (broadcast) channels, I wonder why the book spends so much time on them while nobody uses them.

Pepijn
  • 4,145
  • 5
  • 36
  • 64

2 Answers2

9

Well first of all the book happened before the implementations. Therefore your question is better formulated as:

Why does no implementation of CSP put a major focus on events even though the book emphazises them greatly.

Basically, making events a first-class citizen of a language gives it a certain usage specificity that would probably be too narrow for a general purpose programming language.

Additionally, you can easily implement events on channels (and other constructs), in case you are into event driven programming.

greatwolf
  • 20,287
  • 13
  • 71
  • 105
thwd
  • 23,956
  • 8
  • 74
  • 108
  • 2
    This latter remark is tautologous. CSP and channels naturally provide an event-driven style. The difference is that channels *do not* require callbacks to handle events. – Rick-777 Jul 11 '13 at 23:35
  • 1
    It's much more locking/unlocking than events. The thing transmitted through a channel can be anything. – thwd Jul 12 '13 at 07:02
2

In Occam-pi, barriers are an important adjunct to channels. With a barrier, each enrolled process waits on the barrier until they have all done so. At this point they are all released. This is an example of a non-channel form of CSP event.

Occam-pi also has an extended rendezvous using channels. This is a quite different pattern of usage of channels, very similar to the rendezvous in Ada.

Rick-777
  • 9,714
  • 5
  • 34
  • 50
  • Is this the same concept as CyclicBarrier in Java? http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/CyclicBarrier.html – Pepijn Jul 11 '13 at 14:39
  • I think they're broadly similar in concept. I don't know whether they're the same in fine detail. The Occam-Pi barrier has a highly efficient implementation (as are all of its synchronisation primitives). – Rick-777 Jul 11 '13 at 23:33