Re: [External] The history of the term "to block on a channel"

On 29 Sep 2014, at 13:33, Rick Beton <rick.beton@xxxxxxxxx> wrote:

As Roger mentioned, the terms synchronous and asynchronous are widely used outside of their original clocked vs unclocked meanings. Many people would describe a zero-buffer channel as "synchronous" but an infinite-place buffer channel as "asynchronous" because the sender never waits in the latter case. This terminology is flawed in my view; how do you differentiate between an infinite-buffer channel and a one-place buffer channel? The latter could behave "synchronously" or "asynchronously" depending on the current dynamic state; clearly, using synchronous and asynchronous in this way lacks rigour. Alas, it seems to be pervasive though.

I’m not sure ‘asynchronous’ should ever apply to clock synchronisation, specifically. Anyway, I think it’s more worthwhile to debate appropriate use of terms now than what their history might have been.

In teaching both hardware and concurrent-process programming, I found it useful to first distinguish ‘synchronous’ and ‘asynchronous’, according to whether both parties must be ‘ready’ prior to communication taking place, or equivalently whether either party might be required to ‘wait’ (suspend execution). Of course, this only concerns implementation, not the semantics of the program, whose trace merely records the common ‘event’ of actual communication. I’d then describe ‘asynchronous’ communication according to the ability of the sender to “fire and forget”, and point out the problem which arises if the receiver tries the same trick (when no message might have arrived). I would illustrate the distinction with a contrast between using the phone (when both parties must first be ready) and email.

I’d then distinguish the three known forms of synchronisation permitting synchronous communication : common clock (as in current digital systems), handshake (used in a typical system bus) and rendezvous.

I found the above a useful platform on which to progress, and I propose its adoption where possible, though I’ve never found any complete and coherent account in print.

If I got it wrong anywhere (or missed anything) then it’s a little late for my poor students, but I’m not yet too old to learn.

Regarding (necessarily finite) buffered communication, is that not just a relative of 'simple' synchronous communication (zero-slot buffer), where either party must ‘wait’ (when buffer is empty/full), however synchronisation (with the buffer) is performed? … where both implementation and semantics depends directly on the buffer size. The buffer size does not need to approach infinity for communication to effectively become asynchronous (but for when buffer is empty!). It merely needs to be large enough for the application concerned. (Good luck determining that!) I think this approach lacks more than rigour…

Ian

Ian East

ian.east@xxxxxxxxxxxxxxxxxxxxxxxxx

Open Channel Publishing Ltd.

(Reg. in England, Company Number 6818450)