math/rand: no non-default concurrency-safe Source

[krancour]

I apologize if this is a duplicate issue. I looked and couldn't quite find this one...

According to math/rand package documentation, the following is not concurrency safe:

var seededRand = rand.New(rand.NewSource(time.Now().UnixNano()))

NewSource returns a new pseudo-random Source seeded with the given value. Unlike the default Source used by top-level functions, this source is not safe for concurrent use by multiple goroutines.

The aforementioned "default source," is (rightfully) not exported by the math/rand package. So the only way to generate random numbers in a concurrency-safe fashion (with this package, at least) is to resort to using package level functions that rely on the default, concurrency-safe source.

To seed that, one must make a call similar to the following:

rand.Seed(time.Now().UnixNano())

But this is equally a problem! Why? Because nothing prevents any other bit of code from also seeding/re-seeding the math/rand package-level default source. Consider the possibility that some third party package that is initialized after one has seeded the source re-seeds the source with a constant-- bye, bye, psuedo-randomness; hello determinism.

The bottom line here is that achieving concurrency safety with math/rand forces one down a path that's dependent on package-level globals and that introduces its own problems. It's out of the frying pan and into the fryer, and that is (for me at least) making the package nearly unusable.

[ianlancetaylor]

It seems straightforward to wrap a mutex around your calls to a Source.

That said, do you have a suggestion for how the package should be changed?

[josharian]

In Go 2 world, we could have the default source be non-concurrency-safe, and provide a convenience wrapper that accepts a Source and returns a concurrency-safe Source. (There may be some subtleties and/or optimizations that just throwing a mutex won't help with, like batching core PRNG calls for rand.Read.)

(I have a partially written Go 2 math/rand proposal. I had in mind this being a part of it, but I hadn't gotten to working this part of it yet.)

[krancour]

It seems straightforward to wrap a mutex around your calls to a Source

I suppose I could and probably will. But, should I have to? imho if something in the standard library implicitly requires me to wrap something in a mutex just to use it safely, then it should have done that for me. (This is, in fact how the package level default source works. It's a locking source that utilizes a mutex. At minimum, it would be nice if that source impl or something similar to it were exported so I could use it.)

[gopherbot]

Change https://golang.org/cl/10161 mentions this issue: x/exp/rand: new rand package

[dr2chase]

Would a deterministic parallel random number generator work for you?
E.g., http://supertech.csail.mit.edu/papers/dprng.pdf

[andybons]

I suppose I could and probably will. But, should I have to? imho if something in the standard library implicitly requires me to wrap something in a mutex just to use it safely, then it should have done that for me. (This is, in fact how the package level default source works. It's a locking source that utilizes a mutex. At minimum, it would be nice if that source impl or something similar to it were exported so I could use it.)

There are a lot of constructs in the standard library (and language) that require you to wrap them in a mutex or use channels in order to avoid creating race conditions.

It would be helpful to have your desired change in a proposal format (https://golang.org/s/proposal) so that we can better understand what exact changes we’d make along with motivating examples on why the status quo is unusable for you.

[krancour]

I think I've stated the case clearly and succinctly. I'm not sure what information is missing (warranting the "WaitingForInfo" label) or what the benefit of a more elaborate proposal would be.

[andybons]

There is precedent with the log package. Moving this to a NeedsDecision.