· So wait and signal are pairs by Dijkstra
· But send and receive would be the word-pairs of channels, and block an extra dimension.
· So to call this wait, as suggested by Roger, I don’t know. It interferes with the Dicjkstra’s name space. But that may be ok, of course. Language isn’t that rigid. And Dijstra is dead
· But I still keep yield/wait in a 6/4 liking!?
Of course if we go back even further there were semaphores to which Dijkstra gave the names P and V for the operations on semaphores and as I understand it P and V were the first letters of the Dutch words for wait and signal.
Just a thought.
Any way in my book which is about to be published I have the following description of channel communication between processes:
"A channel is the means by which a process communicates with another process. A channel is a one-way, point-to-point, unbuffered connection between two processes. One process writes to the channel and the other reads from the channel. Channels are used to transfer data from the outputting (writing) process to the inputting (reading) process. If we need to pass data between two processes in both directions then we have to supply two channels, one in each direction. Channels synchronise the processes to pass data from one to the other. Whichever process attempts to communicate first waits, idle, using no processor resource until the other process is ready to communicate. The second process attempting to communicate will discover this situation, undertake the data transfer and then both processes will continue in parallel, or concurrently if they were both executed on the same processor. It does not matter whether the inputting or outputting process attempts to communicate first the behaviour is symmetrical. At no point in a channel communication interaction does one process cycle round a loop determining whether the other process is ready to communicate. The implementation uses neither polling nor busy-wait-loops and thus does not incur any processor overhead."
Don't worry I will tell every one when the book is actually available!
occam-com-request@xxxxxxxxxx [occam-com-request@xxxxxxxxxx] on behalf of tony [tony@xxxxxxxxxxxx]
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.
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
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  and there is a discussion thread on golang-nuts . I include the figure here (and the intro text in golang-nuts):
(I alse dare take comments on the idea.. Here, there or there)
Med vennlig hilsen / Best regards
Senior utviklingsingeniør, siv.ing. / Senior Development Engineer, M.Sc.