Skip to content

gh-118392: Update genrand_uint32 to use atomic operation #118393

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

Closed
wants to merge 1 commit into from

Conversation

corona10
Copy link
Member

@corona10 corona10 commented Apr 29, 2024

@corona10
Copy link
Member Author

corona10 commented Apr 29, 2024

@pitrou @colesbury cc @rhettinger
I am not sure if this change will be safe(or even acceptable) or if it needs some changes for a better, safe random algorithm.

Comment on lines +143 to +144
int index = FT_ATOMIC_LOAD_INT(self->index);
if (index >= N) { /* generate N words at one time */
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this will work well. This can end up returning the same generated numbers to different threads, which we don't want.

Copy link
Member Author

@corona10 corona10 Apr 29, 2024

Choose a reason for hiding this comment

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

Hmm in that case, should we change the algorithm(thread-safe one) or fine-grained locking for this use case?

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think there's a simple fix to the random module.

I commented on the issue. It'd be helpful to document the behavior and provide alternatives. For example, Java's java.util.Random includes the following comment:

Instances of java.util.Random are threadsafe. However, the concurrent use of the same java.util.Random instance across threads may encounter contention and consequent poor performance. Consider instead using ThreadLocalRandom in multithreaded designs.

Copy link
Member Author

Choose a reason for hiding this comment

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

I commented on the issue. It'd be helpful to document the behavior and provide alternatives. For example, Java's java.util.Random includes the following comment:

Okay sounds acceptable :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants