On 11/10/2023 3:19 PM, Bruno Haible via Cygwin wrote:
ISO C 23 § 7.24.2.1 and 7.24.2.2 document how rand() and srand() are expected to behave. In particular: "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. ... The srand function is not required to avoid data races with other calls to pseudo-random sequence generation functions. ..."The two attached programs call srand() in one thread and then rand() in another thread. There is no data race, since the second thread is only created after the call to srand() has returned. The behaviour in Cygwin is that the values in the second thread ignore the srand() call done in the first thread.
Since the standard is trying to be precise, this reads to me as though Cygwin/(newlib?) has chosen to avoid race conditions by making pseudo-random sequences in different threads independent. Although the standard does not require this, it does not prohibit it either.
How to reproduce the bug: $ x86_64-pc-cygwin-gcc -Wall rand-in-posix-thread.c $ ./a or $ x86_64-pc-cygwin-gcc -Wall rand-in-isoc-thread.c $ ./a Expected output: Value from main thread: 1583559764 Value from separate thread: 1583559764 Actual output: Value from main thread: 1583559764 Value from separate thread: 1481765933
-- 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
