On Sun, Jul 17, 2016 at 9:25 AM, Scott Cotton <w...@iri-labs.com> wrote:
>
> I'm well aware of the benefits of non-deterministic select for many use
> cases, I don't contest that at all or the decision to have it part of
> golang.
>
> A clear and concrete problem is the following: The sat solver competition
> at satcompetition.org requires
> deterministic solvers for reproducible results. Suppose I have a
> select{...} in a go program which solves sat,
> and I want to enter it in the contest. I can't. Also, others can't
> reproduce the results. Also, the problem is hard
> and very heuristic so minor variations can cause huge differences in runtime
> (like 1s vs. 1 month).
If the results of your program depend on the choices made in a select
statement or in goroutine execution, then your program is in some
sense racy. It's not necessarily racy in a way that causes undefined
execution, but it's still racy in the sense that your results become
unpredictable. The answer to the problem is not to pin down the
precise choices made by select statements and by the scheduler, it's
to not write racy programs.
I'm not just being facetious: on a multi-processor system with
GOMAXPROCS > 1, there is no way to pin down the scheduler sufficiently
to ensure that the same program choices are made each time. So if
your results change based on scheduler decisions, you have no hope of
reproducible results. Don't write your program that way.
Ian
--
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.
For more options, visit https://groups.google.com/d/optout.
