Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify status of RNG being thread-safe #46280

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
address feedback
  • Loading branch information
alecloudenback authored Aug 12, 2022
commit f1f59003864e4a304f301105524ba605aa037f1b
2 changes: 1 addition & 1 deletion stdlib/Random/docs/src/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ The PRNGs (pseudorandom number generators) exported by the `Random` package are:
Most functions related to random generation accept an optional `AbstractRNG` object as first argument.
Some also accept dimension specifications `dims...` (which can also be given as a tuple) to generate
arrays of random values.
In a multi-threaded program, you should generally use different RNG objects from different threads or tasks in order to be thread-safe. However, the default global RNG is thread-safe as of Julia 1.3 (using a per-thread RNG up to version 1.6, and per-task thereafter). The global RNG refers to per-thread RNG instances; If you instantiate a non-global RNG, you should create a new RNG instance for each thread to avoid possible data-races.
In a multi-threaded program, you should generally use different RNG objects from different threads or tasks in order to be thread-safe and deterministic (if given a specific seed). However, the default global RNG is thread-safe as of Julia 1.3 (using a per-thread RNG up to version 1.6, and per-task thereafter). The global RNG refers to per-thread RNG instances; If you instantiate a non-global RNG, you should create a new RNG instance for each thread to avoid possible data-races.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The

The global RNG refers to per-thread RNG instances; If you instantiate a non-global RNG, you should create a new RNG instance for each thread to avoid possible data-races.

seems like it is just saying the same thing as the earlier stuff in the paragraph again?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here was my confusion so maybe there's a clearer way to get this across. Per the prior docs:

  1. The global RNG is thread safe
  2. Xoshiro is used as the global RNG
  3. Therefore, if I use a newly instantiated Xoshiro (call it X), I can have code in multiple threads reference X without issues.

#3 is not correct because the Global RNG is constructed in a way that makes it thread safe and that's the point that I don't think comes across previously and what

The global RNG refers to per-thread RNG instances; If you instantiate a non-global RNG, you should create a new RNG instance for each thread to avoid possible data-races.

Is trying to differentiate from what was stated before.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to clarify in the latest commit


The provided RNGs can generate uniform random numbers of the following types:
[`Float16`](@ref), [`Float32`](@ref), [`Float64`](@ref), [`BigFloat`](@ref), [`Bool`](@ref),
Expand Down