Communicating to fellow programmers that the concept of blocking in process-oriented design is perfectly acceptable, while using a word with basically negative connotations, is difficult. The bare need to do it often means that misunderstanding this concept is common and harmful. The first contender on a “blocking” channel has alternatively been said (by several people) to wait (rather than block) on the channel. This seems a more accurate description and is certainly more positive.

A better correspondence between the negative meaning and semantics is when “blocking” describes serious side effects on the temporal properties of other concurrent components. This is the correctly feared blocking.

One example is when a process has too many internal work-tasks to handle and any one such cannot acceptably “block” for other work tasks for too long. The “blocking-on-each-other” blocking type that we know as deadlock is perhaps the worst kind. A system cannot survive for long should this happen (in a sub-system, say).

When the literature over the last years talks about non-blocking algorithms, it has in fact been talking about the “waiting” type. It might be easier to refer to this when describing the semantics of a synchronous (and, in this context, non-blocking) CSP type channel. The same could be reasoned of the interface-RPC-call or entry type mechanisms of Ada and xC: i.e. that they are the “waiting” type. To gain understanding and acceptance of these types of solutions, we should simply avoid the “blocking” term in the CSP context. Phrases like “wait”, “yield”, “synchronous” and “non-buffered” should suffice. This fringe presentation will explore this further and invite discussion. Slides used in the presentation can be downloaded from [1].