[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Guys

this is so great! Thanks for letting me copy your texts! I hope it's clear that being in that note doesn't mean that you necessarily support my views. I'll add a disclaimer about that.

In the copies I was tempted to emphasize some with a red vertical line - which has now been removed! That was plain wrong! Sorry!

It is interesting to see the golang-nuts and golang-dev communities compared to this group's knowledge. This is rock solid, the other is more or less believeing this and that. But the core people show up now and then. And some whi are active are really good, as well.

Shouldn't we make a new google group and move our discussions open in the future? Something with a modern name etc. No, I won't be the admin, it must be someone young! Young??

Øyvind

29. sep. 2014 kl. 16:19 skrev Larry Dickson <tjoccam@xxxxxxxxxxx>:

I think Rick’s observation is very pertinent. In designing the Graphics Slave (now released, by the way — see 
https://www.kickstarter.com/projects/767046121/crawl-space-computing-with-connel/posts ), I had to deal with Windows’ “callback” approach to graphics events. This does nothing that a CSP-type channel approach cannot do, nor does it give quicker response (on the contrary — as the Linux XCB graphics shows), and callbacks are far more complicated, incomprehensible and error-prone. But it allows the pretense that communications are “non-blocking,” by hiding what Rick calls the “state progressions,” which of course are blocking.

Non-blocking in the sense of buffered output is more understandable, because it really does provide some extra utility, and it is NOT incomprehensible. By explicitly programming an ack, you can force it to behave in an “occam-like” fashion if you want. This is what I did in Connel, since all the common channel-analogues offered by modern OSs seem to be buffered.

Larry

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

Hi, 

The 'blocking' terminology issue seems to me also to be tied up with OS terminology. In particular, standard APIs exist for blocking I/O and for non-blocking I/O, which typically use (or avoid) mutex locks. In the non-blocking I/O case, the OS API provides some means of registering callbacks to deal with state progressions.

The same is very much true for the Java virtual machine also.

For this reason and for reasons others have mentioned, I feel that it is wrong to describe channels with this terminology because it evidently causes nuances and misunderstandings in those not very familiar with a CSP or Occam way of doing things. 'Waiting' on a channel communication is helpfully different.

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.

Rick





On 29 September 2014 11:33, Roger Shepherd <rog@xxxxxxxx> wrote:
Øyvind

The issue in telephones is precisely whether the switch allows another call to be established or whether some calls may be blocked because a circuit cannot be established.

Roger

On 29 Sep 2014, at 11:21, Teig, Oyvind BIS <Oyvind.Teig@xxxxxxxxxxxxxxxx> wrote:

Chris and Roger
 
..and this again corresponds to the Wikipdia article about Non-blocking algorithm (perhaps by accident), since the telephone connection does not take other connections into consideration (that trying to call on one line should not stop the others from getting a connection)? Or was this actually what they were afraid of the twenties or whenever: that they should design the exchanges, cabling etc. so that they did not side effect into other connections and effectively blocked them?
 
Øyvind
 
Fra: Roger Shepherd [mailto:rog@xxxxxxxx] 
Sendt: 29. september 2014 12:03
Til: Jones, Chris C (UK Warton)
Kopi: Larry Dickson; Matt.Pedersen@xxxxxxxx; Teig, Oyvind BIS; occam-com@xxxxxxxxxx; "Øyvind Teig (oyvind.teig@xxxxxxxxxxx)"; David May
Emne: [External] Re: The history of the term "to block on a channel"
 
Chris,
 
This sounds likely and the difference between this and what happens in a (for example) occam program is interesting. In an occam program the communication channel is always available, however the “other party” is not. So, in the telephone sense the communication is non-blocking - it’s just that the other party might not be there, and if you are making a call (output) you have have to hang on the line until the other party answers. 
 
Roger
 
 
On 29 Sep 2014, at 10:55, Jones, Chris C (UK Warton) <chris.c.jones@xxxxxxxxxxxxxx> wrote:


I suspect the term has been lifted from the telecoms industry where telephone exchange equipment was considered to be non-blocking when a caller was guaranteed always to be able to get an immediate connection to another non-busy user on a fully functioning, non-blocking exchange.  In the UK, local exchanges were non-blocking while trunk connections were not.
 
I would have thought the usage referring to the possibility of sending a communication was still pertinent.
 
Chris
 
 

Prof. Christopher C R Jones BSc. PhD C.Eng. FIET

BAE Systems Engineering Fellow

EMP Fellow of the Summa Foundation

Technologist Consultant – Lightning, EMP & CEM     <image001.jpg>
 
Military Air & Information                                                 ( Direct:  +44 (0)1772 8 54625
Electromagnetic Engineering, W423A                           ( Mobile:  +44 (0)7855 393833
Engineering Integrated Solutions                                  7 Fax:      +44 (0)1772 8 55262
Warton Aerodrome                                                           * E-mail:   chris.c.jones@xxxxxxxxxxxxxx 
Preston                                                                              : Web:      www.baesystems.com
PR4 1AX
 
BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687
 
Exported from the United Kingdom under the terms of the UK Export Control Act 2002 (DEAL No ####)
 
From: occam-com-request@xxxxxxxxxx [mailto:occam-com-request@xxxxxxxxxx] On Behalf Of Larry Dickson
Sent: 27 September 2014 18:32
To: Matt.Pedersen@xxxxxxxx
Cc: Roger Shepherd; Teig, Oyvind BIS; occam-com@xxxxxxxxxx; "Øyvind Teig (oyvind.teig@xxxxxxxxxxx)"; David May
Subject: Re: The history of the term "to block on a channel"
 
 
*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding 
Red Flags that you can look out for in emails you receive, click here.
If you feel the email is suspicious, please follow this process.

It seems to me that “blocking” applies to an alt as well as a one-to-one communication (or to a timer). It’s not something that CSP people need to be embarrassed about. On the contrary. Any model that does NOT account for blocking is a false model. Think on the instruction level. Each sequential logic primitive (like an add or multiply) is a wrapper around some combinatorial logic that needs time to settle. The system clock gives it that time — so every instruction blocks! And if it did not block, it would give incorrect results.
 
Before an instruction completes, the conditions necessary for its completion have to hold. If this is a read, write, alt, or timeout, the required blocking can be “macroscopic,” and efficient chips yield control of the instruction stream to other tasks at that point.
 
Larry
 
On Sep 26, 2014, at 2:22 AM, matt.pedersen@xxxxxxxx wrote:



Blocking is probably used because a read or write will do exactly that in a one to one straight up communication. Though used in an alt blocking might not aptly describe the state as only communications that are ready (i.e., will _not_ block) will be considered. 
I dislike yield because yield gives the idea that you can back off from a blocking read or write call which you cannot. 
 
Matt


On Sep 26, 2014, at 2:19, "Roger Shepherd" <rog@xxxxxxxx> wrote:

Oyvind,
 
I don’t know the answer to you question.
 
I can’t say that I like “block” - but it usage is certainly old and is common for multitask systems where the ability to create an extra task/thread/whatever to do communication is considered to be advantageous - hence “non-blocking communication”.
 
I don’t like “yield” either as this has a meaning along the lines of "to give place or precedence (usually followed by to):  to yield to another; Will the senator from New York yield?” (from dictionary.com) and it is not necessarily the case the case that there is anything else to yield to. 
 
I prefer “wait”.
 
On the subject of language, I think the term “synchronous” is plain wrong when used to describe (occam) channel communication. The processes are “synchronised” by the communication; the communication is “asynchronous” - there is no clock which causes the communication to happen.
 
Roger 
 
 
On 26 Sep 2014, at 07:27, Teig, Oyvind BIS <Oyvind.Teig@xxxxxxxxxxxxxxxx> wrote:



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):
<image001.jpg>
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)
 
 
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)
 
 

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

 

--
Roger Shepherd
rog@xxxxxxxx


--
Roger Shepherd
rog@xxxxxxxx







Øyvind TEIG 
+47 959 615 06
oyvind.teig@xxxxxxxxxxx
http://www.teigfam.net/oyvind/home
(Mac)