On 29 Sep 2014, at 13:33, Rick Beton <rick.beton@xxxxxxxxx> wrote:
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…