Hah, you knew about that! I have believed that the reason for our yielding rule is because of the snow (that we unfortunately (donât tell anybody)) have in the winter. Itâs not a good idea to paint the rules (lines, dotted lines) on the road in that case. So we have have these signs and that rule. But there may be a psychological reason as well, like nobody else has it..
Yield/Wait still 6/4 for me
But âconsensualâ I really like. But can you make other forms out: To âconsense on a channelâ and âconsensing on a channelâ. That would be great, but.. And I canât replace it with âagreeâ either.
But I will start to use consensual in my blog notes, after I have told about how channels might yield..
âYieldâ implies to give way and that one person/process therefore has priority over another.
Norway, in driving, has an additional yield concept that doesnât exist in other places (and certainly not the UK) â the inverted Y sign which instructs drivers to merge (yield) in turn where two lanes turn into one. So I donât know if Oyvind thinks of âyieldâ as being symmetric whereas in the UK there is more of a nuanced âpriorityâ in the concept of yield.
Occam channels are a synchronisation point, but that doesnât mean they are synchronous â there is no clock tick â they are asynchronous in that the communication takes place at some point when both ends of the communication are ready, and it is not determined in advance which one is ready first.
I was in Zurich the last couple of days and it was pointed out to me that Swiss politics are based on consensus; Occam channels strike me more as âconsensusâ than âyieldâ. Consensual Communications, maybe?
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: Marc Smith [mailto:mlsmith@xxxxxxxxxx]
I think you have hit upon a significant language barrier when we discuss channel communications outside of our CSP community. Even though I have heard the phrase "to block on a channel" I never really thought of it as blocking. Not to add another term to the mix -- but what you describe as yielding, I thought of as synchronizing. Every communication over a 1-to-1 channel is a synchronization between two processes. When one process reads what another process has written to a channel, they are synchronizing on that event.
To communicate is to synchronize. We already use the term synchronous to describe our channels. What I like about synch'ing versus yielding is a little nuanced. To yield is an intentional act ("after you...", "no, after you...", etc.), which may take away from the intentional act of reading or writing. Yielding is something that may happen to a process if it attempts to read or write, and the process on the other end isn't ready to reciprocate.
On the other hand, when I think of synchronization, I think of it as what happens as a matter of course when a process attempts to read or write to a channel. The synchronization is built-in, by definition of communicating over a synchronous channel.
So that's the difference to me between yielding and synch'ing. It is admittedly a nuanced difference, and I don't know that I ever articulated it before, to myself, or anyone else. So, thank you for that. :-)
The term blocking never bothered me because I just understood it in the sense of synch'ing. But I see your point about impressions this terminology unintentionally makes on the rest of the concurrency community.
On Fri, Sep 26, 2014 at 7:41 AM, Teig, Oyvind BIS <Oyvind.Teig@xxxxxxxxxxxxxxxx> wrote: