runtime: enable scheduler randomization independent of the race detector

[josharian]

-race does scheduler randomization. This has proved to be a useful way to flush out logical races, bad lock orderings, etc.

However, running with the race detector enabled (a) is slow and (b) is only supported on a subset of platforms.

I propose that we make it possible to run with scheduler randomization enabled, independent of whether the race detector is enabled.

I believe that this could be done entirely at run time, perhaps via a GODEBUG flag.

cc @dvyukov @bradfitz @aclements @mknyszek

[mvdan]

Out of curiosity, is this something that could simply be turned on at all times, similar to how ranging over a map is always pseudo-random with the Go toolchain? Assuming that the cost is negligible, it could be a net win.

[prattmic]

This seems like something that could be made into a GODEBUG option without issue. I doubt the few branches it would add will be noticeable.

I'm not sure what the cost is, but if low enough I think enabling all the time could be interesting as well.

[ianlancetaylor]

I took a look at randomizeScheduler. I think the only noticeable cost would be an additional loop in runqputslow, which is called to move half of a local run queue to the global queue. That additional loop will be over the goroutines being moved to the global queue. Currently I think it can be up to 128 entries. Since runqputslow is only called when the local run queue is full, this isn't going to be particularly common. There would also be a bunch more calls to fastrand.

So while of course someone would have to benchmark this, it seems plausible that the cost would be fairly low.

[dvyukov]

@ianlancetaylor note that there maybe a significant cost related to loss of scheduling locality in runqput.