> > > For concurrent programs, obviously the program needs to be race-free -- no > reads of data that could hold different values based on grouting scheduling > of writes (using happens-before). > > Indeed, this is the definition of "racy" we're interested in. As Ian pointed out, this is distinct from data race bugs, where behavior is undefined.
> I would also note that usage of a channel which has more than one receiver > goroutine or more than one sender goroutine at any time will introduce > non-determinism. > Not necessarily. You may decide to send multiple intermediate results through a channel (say, integers), then have a reducer drain the channel in a manner where order doesn't matter (say, find the max). I think the behavior of this example is well-defined, and it is "determinist" because both the result and the performance are consistent from run to run, even if the order of the values read from the chan is undefined. > It is not clear to me what is a legitimate "side effect" in your list. > What is the difference between a side-effect and > whether the program will generate the same output in all schedulings? > In this context, I named "side-effect" a variation on result or performance. Variation on result would be a bug. Big variation on performance could result from a violation of the non-raciness as defined above. What if select choice order or channel operation orderings have only > performance impact and no side effects w.r.t. correctness, race-freeness, > or output of the program? I would like to be able to reliably reproduce > that. > Indeed it would be interesting to make the select determinist/reproducible by changing the cputicks() policy. But I suspect it would be a better idea to design the program so that the select choice never really matters for result and perf. If the select choice order has a small* performance impact, then leave it as-is. If the select choice order has a big* performance impact, I would call this an undesirable side effect. The implicit distinction I make between small and big performance impact is informally this : small impact when within the order of magnitude of CPU and scheduler contingencies (except starvation), usually less than 400%. Big impact is unbounded delay, like launching a big task B that may have been pruned in another run of the same program. -- 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.
