[all-commits] [llvm/llvm-project] 86860b: [libc] Make 'rand()' thread-safe using atomics ins...

[Joseph Huber via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 86860be2886283210083e5e3f20048e559cc059e
      https://github.com/llvm/llvm-project/commit/86860be2886283210083e5e3f20048e559cc059e
  Author: Joseph Huber <huberjn at outlook.com>
  Date:   2024-06-26 (Wed, 26 Jun 2024)

  Changed paths:
    M libc/src/stdlib/CMakeLists.txt
    M libc/src/stdlib/rand.cpp
    M libc/src/stdlib/rand_util.cpp
    M libc/src/stdlib/rand_util.h
    M libc/src/stdlib/srand.cpp
    M libc/test/src/stdlib/rand_test.cpp

  Log Message:
  -----------
  [libc] Make 'rand()' thread-safe using atomics instead of TLS (#96692)

Summary:
Currently, we implement the `rand` function using thread-local storage.
This is somewhat problematic because not every target supports TLS, and
even more do not support non-zero initializers on TLS.

The C standard states that the `rand()` function need not be thread,
safe. However, many implementations provide thread-safety anyway.
There's some confusing language in the 'rationale' section of
https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html,
but given that `glibc` uses a lock, I think we should make this thread
safe as well. it mentions that threaded behavior is desirable and can be
done in the two ways:

1. A single per-process sequence of pseudo-random numbers that is shared
by all threads that call rand()
2. A different sequence of pseudo-random numbers for each thread that
calls rand()

The current implementation is (2.) and this patch moves it to (1.). This
is beneficial for the GPU case and more generic support. The downside is
that it's slightly slower to do these atomic operations, the fast path
will be two atomic reads and an atomic write.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications