Random: support threads for GLOBAL_RNG access

[vtjnash]

No description provided.

[JeffBezanson]

From triage: make default global RNG per-thread for now. Document that explicit RNG objects are not thread-safe.

[StefanKarpinski]

General thoughts from triage:

• calling rand() should be thread-safe even if there's a performance hit
• people are comfortable with changing the default rng to PCG64/Xorshift128whatever
  • including this with multithreading might help with popularity since it combines good with bad
• using a PRNG with a small state might help since we can use atomics
• explicit RNG objects are not thread-safe, if you want to use them from multiple threads, use locks

[StefanKarpinski]

Calling the function to get the global RNG get_local_rng is a bit confusing. I know it's thread-local, but it's global in the sense of scope. Maybe get_thread_rng?

[StefanKarpinski]

Or maybe just default_rng()?

[JeffBezanson]

Rebased to pick up #32604.

I think we can merge this, and think about the naming convention for functions like this. I know people might start using it, but it's not exported and we'll have time to rename it if we want before 1.3.

[JeffBezanson]

I'm not sure whether this is thread safe.

[vtjnash]

Yeah, I still need to push my local fork which fixes some stuff like this. Was just waiting on the outcome of the naming discussion.

[rfourquet]

Or maybe just default_rng()

I agree with this suggestion, and had the same idea when reading this PR the first time. I find both get_local_rng() and get_global_rng() confusing, while default_rng() conveys the practical meaning without implementation details (if I may!) considerations (default_rng() naming works independantly of the threading abilities of the runtime, and in fact there was at one point an unexported function defaultRNG() = GLOBAL_RNG).

[rfourquet]

The _GLOBAL_RNG thing is rather clever! Do I get it right that it's only to avoid breaking code and that it's intended to be removed in v2?

[mauro3]

What is the reason that in this PR separate RNG stream are created (link to code) instead of using the "trick" advocated in the docs of using just one chain but sampling from different locations (implemented using the Future.randjump)?

Wikipedia (fourth bullet) suggests that at least for MCMC the randjump strategy should be used. Or are the seeds of the separate streams chosen such that inter-stream numbers are non-correlated too? This line suggest that no such approach is taken.