On Mon, Nov 13, 2023 at 10:33:48PM +0100, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > I took a look into POSIX and I'm a bit puzzled now. From > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html > > Part of the confusion is that POSIX and ISO C have slightly different > wording. This POSIX page says: > "The functionality described on this reference page is aligned > with the ISO C standard. Any conflict between the requirements > described here and the ISO C standard is unintentional. This > volume of POSIX.1-2017 defers to the ISO C standard." > > In ISO C 99 § 7.20.2, the only relevant sentence is: > > "The srand function uses the argument as a seed for a new sequence > of pseudo-random numbers to be returned by subsequent calls to rand. > If srand is then called with the same seed value, the sequence of > pseudo-random numbers shall be repeated." > > In ISO C 11 § 7.22.2 and ISO C 17 § 7.22.2, additionally two sentences > were inserted: > > "The rand function is not required to avoid data races with other > calls to pseudo-random sequence generation functions." > > "The srand function is not required to avoid data races with other > calls to pseudo-random sequence generation functions." > > ISO C 23 (which is still is draft state, but compared to the draft > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf I cannot > see any change regarding rand() in the changes summary > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3148.doc) has the > same wording. > > POSIX does not have these two sentences, but instead has: > > "The rand() function need not be thread-safe."
I read the above as requiring *reentrancy*, but not *thread-safety*. If multiple threads are accessing rand() and rand() accesses global state, the global state should not get corrupted; the sequence generated by rand() should remain intact. Since thread-safety is not guaranteed, is it theoretically possible that multiple threads enter rand() at nearly the same time and both get the *same* random value in the sequence. (Whether or not that is undesirable behavior is application-specific.) A mutex can avoid this theoretical duplication, as can using thread-local state (with difference seeds) instead of global state. If the seed value is the same in multiple threads using thread-local state, the sequence of random values generated in each thread will be repeated in each thread. This may be surprising behavior to some when srand() is called, then multiple threads spawned, and each thread subsequently gets the same sequence of values from rand(). If the global state is a single item and atomics can be used to access and update the global state, then an implemntation can use atomics instead of mutexes to achieve thread-safety, which is allowed by the standards, but not required for rand(). Cheers, Glenn -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
