ÃyvindThe 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.RogerOn 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ÂÂ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 FoundationTechnologist Consultant â Lightning, EMP & CEMÂÂÂÂÂ<image001.jpg>ÂMilitary Air & InformationÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ(ÂDirect:Â +44 (0)1772 8 54625Electromagnetic Engineering, W423AÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ(ÂMobile:Â +44 (0)7855 393833Engineering Integrated SolutionsÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ7ÂFax:Â ÂÂÂ +44 (0)1772 8 55262Warton AerodromeÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ*ÂE-mail:ÂÂÂchris.c.jones@xxxxxxxxxxxxxxÂPrestonÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ:ÂWeb:ÂÂÂÂÂÂwww.baesystems.comPR4 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 ####)ÂÂ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  and there is a discussion thread on golang-nuts . I include the figure here (and the intro text in golang-nuts):<image001.jpg>ÂÂÂÂ1.ÂÂÂÂÂ2.ÂÂÂÂÂ3.ÂÂÂÂÂÂÂ(I alse dare take comments on the idea.. Here, there or there)ÂÂMed vennlig hilsen / Best regardsÃyvind TeigSenior utviklingsingeniÃr, siv.ing. / Senior Development Engineer, M.Sc.
Autronica Fire and Security AS
Research and DevelopmentÂÂÂ
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.