torsdag 6. mai 2021 kl. 16:44:08 UTC+2 skrev rog:
> On Thu, 6 May 2021 at 14:41, 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> PS: And I'm not saying there is no argument. Maybe "select is not atomic"
>> is such an argument. But if there is an argument and/or if this is that
>> argument, I don't fully understand it myself.
>>
>
> One reason is that the semantics can conflict. Consider this code, for
> example (assuming a hypothetical "pri select" statement that chooses the
> first ready arm of the select) - the priorities conflict. I suspect Occam
> doesn't encounter that issue because it only allows (or at least, it did
> back when I used Occam) select on input, not output. I believe that
> restriction was due to the difficulty of implementing bidirectional select
> between actual distributed hardware processors, but I'm sure Øyvind knows
> better.
>
This is exactly how I have understood it too. Neither occam nor xC has
output guards. Like Go does not have pri select, we'd we have to live with
it. There are reasons. For the transputer (and the xCORE grandchild) it's
multi-core and then the protocolling for also having output guards, they
said, had been more complicated that the need for this. It may be
simulated. But they did introduce something very intersting for some
prospective occam (which never was implemented), which was *extended* input
("??") *and* output ("!!") primitives. Prof Peter Welch "used" them to
prove my "XCHAN"
in
https://www.cs.kent.ac.uk/research/groups/plas/wiki/An_occam_Model_of_XCHANs.
I think they basically bind the other side of the channel to guarantee the
ALT for that special input or output the next time. (If yo ask more I'll
have to refresh it..)
Aside: I have also sat through severeal dicussion on whether it was the
tasks or the messaging that should be prioritised. Occam had two task
priorities where one was thought of for "drivers". It did in theory at
least have both ALT and PRI ALT. xC/xCORE has no task priorities, but they
have like 2 * 8 = 16 logical cores and a scheme to handle (even guarateed
by time limits) deterministic timing, so virtually everything is a
potential "interrupt". As far as I remember, all these discussion ended up
with some agreement that it was the pri select that was to be chosed over
pri par.
func main() {
> c1, c2, c3 := make(chan int), make(chan int), make(chan int)
>
> go func() {
> pri select {
> case c1 <- 1:
> case v := <-c2:
> c3 <- v
> }
> }()
> go func() {
> pri select {
> case c2 <- 2:
> case v := <-c1:
> c3 <- v
> }
> }()
> fmt.Println(<-c3)
> }
>
> That said, I suspect that the semantics could be ironed out, and the real
> reason for Go's lack is that it's not actually that useful; that it would
> be one more feature; and that in practice a random choice makes sense
> almost all the time.
>
I guess so too. Rob Pike, are you there?
This one prints 1 or 2: https://play.golang.org/p/QfiPsh6udgz I cant' twist
my head to see what two *pri selects* might print?
Øyvind
On Thu, May 6, 2021 at 3:40 PM Axel Wagner <axel.wa...@googlemail.com>
>> wrote:
>>
>>> FWIW after all this discussion I *am* curious about a more detailed
>>> argument for why we can't have a priority select that guarantees that
>>> *if* the high-priority case becomes ready before the low-priority one
>>> (in the sense of "there exists a happens-before edge according to the
>>> memory model"), the high-priority will always be chosen.
>>>
>>> That is, in the example I posted above
>>> <https://play.golang.org/p/UUA7nRFdyJE>, we *do* know that `hi`
>>> becoming readable happens-before `lo` becoming readable, so a true
>>> prioritized select would always choose `hi` and never return. The construct
>>> we presented *does* return.
>>>
>>> Now, I do 100% agree that it's not possible to have a select that
>>> guarantees that `hi` will be read if both *become readable concurrently*.
>>> But I don't see a *fundamental* issue with having a select that always
>>> chooses `hi` if `*hi` becoming readable happens-before `lo` becoming
>>> readable*.
>>>
>>> And to be clear, I also kinda like that we don't have that - I think the
>>> value provided by the pseudo-random choice in preventing starvation is
>>> worth not having an "ideal" priority select construct in the language. But
>>> I couldn't really make a good case why we *can't* have it.
>>>
>> --
>>
> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEJNtu1i1RyZxW5FNYkD0TB73nq0WyVCCW_E9_JOAVJmw%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEJNtu1i1RyZxW5FNYkD0TB73nq0WyVCCW_E9_JOAVJmw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/e2500e4c-fe27-4de5-ad7f-0b9ebab177c3n%40googlegroups.com.
