Hi Oyvind
I think it was a common term in use by April 1986 when I joined Inmos. I think some terms in common use were used a bit loosely. A channel that was waiting for the other end of the
communication to become ready “blocked” the process from proceeding. Thus my recollection is that “blocking on a channel” was commonly used to describe a process that couldn’t proceed until the communication could proceed.
I think you have to remember that at the time the transputer came out, lots of people got their hands on it and started parallel programming. Many of these were engineers, without computer
science backgrounds, and so made up the terminology as they went along.
In my own case, I had been programming real time systems (engine controllers, antilock braking etc) in assembler and having graduated in 1975 with a degree in electronic engineering
and physical oceanography, the only formal computer education I had was a 3 day course from the Maths department at university where they had the foresight to teach the engineers Algol instead of Fortran, and some timeshare Basic I had picked up as I went
along in order to do a few assignments.
So when I got to Inmos, I came across terms like “critical sections” and realised that I had been implementing these things in assembler but without knowing the terms or the formal
principles behind them. For me, suddenly in Occam I had a language that described pretty much what I wanted to do. It was my observation that engineers found Occam easier than computer scientists because the CSP model was so similar to engineering – black
boxes and wires, glitches, race conditions etc.
When I moved to Inmos France, I had to find out what people used commonly to describe transputer and Occam related terms in French because they had yet to reach any (computing) dictionary.
So I think that in answer to your question, there are a raft of “formal” terms that were described in the books, but there is also a second group of “informal” terms that people used
to describe things – some are synonyms (equivalent words) to the “formal” terms, but others had slightly different meanings.
This is actually common practice in English – one of the reasons the English language has such a large vocabulary is that English frequently adopts words from other languages (maybe
Anglifying them in the process) to express a slightly different meaning to a word we already have. Over time, that meaning may well change. This is why, when the English are learning French, there are so many words we class as “faux amis” – false friends –
because they sound/look like a French word so we think that it has the same meaning in French. (see
http://www.oxfordlanguagedictionaries.com/Public/PublicResources.html?direction=b-fr-en&sp=S/oldo/resources/fr/Difficulties-in-French-fr.html for some examples)
So I cannot give a direct answer to your question, but hope that this information might point you or others into pinning down the origin or original meaning.
Best regards
Tony Gore
Aspen Enterprises Limited email
tony@xxxxxxxxxxxx
tel +44-1278-761000 FAX +44-1278-760006 GSM +44-7768-598570 URL:
www.aspen.uk.com
Registered in England and Wales no. 3055963 Reg.Office Aspen House, Burton Row, Brent Knoll, Somerset TA9 4BW. UK
From: occam-com-request@xxxxxxxxxx [mailto:occam-com-request@xxxxxxxxxx]
On Behalf Of Teig, Oyvind BIS
Sent: 26 September 2014 07:27
To: occam-com@xxxxxxxxxx
Cc: 'Øyvind Teig (oyvind.teig@xxxxxxxxxxx)'; 'David May (dave@xxxxxxxxxxxxx)'
Subject: The history of the term "to block on a channel"
Sirs
When was the phrase “blocking on a channel” introduced and by whom? Hoare does not use it in his 1985 book. Roscoe almost does not use it, or I would say, he does not use it at all in this context in his version of the
book that’s PDFed. If this group does not know this, none will.
I am suggesting using “to yield on a channel” rather than “to block on a channel”. I have a blog note about it [1] and there is a discussion thread on golang-nuts [2]. I include the figure here (and the intro text in
golang-nuts):
Readers of golang-nuts know that “blocking is fine in Go”. But often, when I talk with other programmers I would hear that “blocking
is evil”. I suggest that we go over to saying that “yielding on a channel is fine”. I’ll explain:
The literate meaning of blocking is about something we don’t want. It means I want to go somewhere but am stopped or delayed
so I arrive too late. Or a door is blocked, in which case we must unblock it, hopefully without a bulldozer. Since this semantics outnumbers the people who understand CSP-based channel semantics we have an explanation problem.
With an explanation problem follows a mission problem.
Tell a basically single-thread programmer in C++ that blocking is good and you ask for much. His attention to try to understand
something rather new, even if he’s used to linux select. Because often the code that does this linux select also does other rather independent matters. And it’s in his spec that these other matters also need to complete. And when you block on one matter it’s
easy to see blocking as something evil. Because he or she is right in their own mind.
So which “blocking” do you mean?
1.
“Blocking on a channel” or some shared resource controlled by a non-blocking algorithm. I believe
these may be in the same group, ref. the Wikipedia page about Non-blocking algorithm
2.
“Blocking” away other required functionality
3.
“Blocking” as in deadlock, where the system cannot proceed, where there is a cycle in the dependency
tree
We already have good words for 2. = blocking as is, and 3 = deadlock. But we reuse blocking for 1.) which is not optimal. As
said, I suggest 1. = yielding. This is an implicit yield that the application doesn’t have control of. Not the explicit yield that some operating systems would supply in the API. The channel semantics as implemented in the scheduler does it for us.
What do you think of this? If we start to write “to yield on a channel” or “yielding on a channel” it could slowly creep into
our language. And the C/C++ (and even Scala or Erlang) people would give us an ear. Especially if we agree with them that blocking is evil.
(I alse dare take comments on the idea.. Here, there or there)
[1] -
http://www.teigfam.net/oyvind/home/technology/092-not-so-blocking-after-all/
[2] -
https://groups.google.com/forum/#!topic/golang-nuts/OSBU8wjlES8
Med vennlig hilsen / Best regards
Øyvind Teig
Senior utviklingsingeniør, siv.ing. / Senior Development Engineer, M.Sc.
Autronica Fire and Security AS
Research and Development
UTC Building and Industrial Systems
Phone: +47 735 824 68
E-mail: oyvind.teig@xxxxxxxxxxxxxxxx
www.autronicafire.no
www.teigfam.net/oyvind/home/
(Also work-related)