Hi Paul.
I looked at your code a bit more. I believe that there might be another
problem. The call to “next” is concurrent with the setting of hi and low.
This means that “next” might get through the first select, get paused, hi and
low be set, then “next” continues and executes the second select. In this
case, the result is nondeterministic – as expected. To “next” it appears that
hi and low were set at the same time.
If you ensure that next does have a chance to run between when hi gets set and
when low gets set, then it works deterministically. You could put a 1ms sleep
between them, for example. Even a “runtime.Gosched()” helps – but it isn’t a
guarantee.
How close together can the hi and low settings be without there being a race?
There is no guaranteed safe interval, but on my machine 1ms was good enough
that there were no “failures” within a one minute test run. On Windows I can’t
sleep for less than 1ms, but I suspect that the real answer is more like 1us
for practical (not absolutely guaranteed) usage. This is assuming the CPU
isn’t loaded, too. J
John
John Souvestre - New Orleans LA
From: John Souvestre [mailto:[email protected]]
Sent: 2017 January 25, Wed 17:02
To: 'golang-nuts'
Subject: RE: [go-nuts] Re: Priority cases in select?
I believe that there is a typo in your example. It seems that you have
separate selects instead of nested selects.
Try: https://play.golang.org/p/YWYhnLJsdS
John
John Souvestre - New Orleans LA
From: Paul Borman [mailto:[email protected]]
Sent: 2017 January 25, Wed 16:01
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Re: Priority cases in select?
I originally was thinking on the lines of what John said, but I proved it
wrong, see https://play.golang.org/p/JwX_cxaR99 for the code. You can't run it
in the playground, but on my MacPro I get output like:
$ GOMAXPROCS=1 go run r.go
Failed after 1137702
Failed after 699376
Failed after 757658
^Csignal: interrupt
$ GOMAXPROCS=2 go run r.go
Failed after 12954
Failed after 63778
Failed after 11831
Failed after 277038
^Csignal: interrupt
So even though hi was clearly written before lo, it is possible to fail the
first select, have hi and lo written (in that order), and then enter the second
select which has a 50% chance on reading from lo, even with GOMAXPROCS set to 1.
On Wed, Jan 25, 2017 at 11:27 AM, John Souvestre <[email protected]> wrote:
I understand what you are saying, but all of these situations are basically
race conditions, aren’t they? So there is no deterministic manner of resolving
them. Thus it doesn’t matter which is chosen. However, in the more general,
non-race, condition I believe that it meets the goals.
John
John Souvestre - New Orleans LA
From: Axel Wagner [mailto:[email protected]]
Sent: 2017 January 25, Wed 13:19
To: John Souvestre
Cc: golang-nuts
Subject: Re: [go-nuts] Re: Priority cases in select?
Doesn't work. If no communication can proceed when entering the select, this
degenerates to a simple select. For example, say there are no writers to any of
those channels. At the same time, that the last select is entered, three
different goroutines start blocking to write to one of the channels each. Even
though priorityHigh could proceed, you will read from one of the other with ⅔
probability.
(a simpler case: Imagine that, while the goroutine is blocking in the innermost
select, a second goroutines enters *the same* select, just with writes.
Semantically, all three communications can proceed at the same time for both
goroutines, so one is chosen uniformly)
This is the fundamental problem with all the nested select solutions; they
assume that the code is evaluated atomically. But in reality, the state of a
communication being possible can change at any point for an arbitrary number of
channels. Thus, you can always construct a sequence where you revert to the
innermost select, violating c.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
