From: "Allen, Norton T." <allen@huarp.harvard.edu>
To: Bruno Haible <bruno@clisp.org>, cygwin@cygwin.com
Subject: Re: rand is not ISO C compliant in Cygwin
Date: Sat, 11 Nov 2023 11:50:30 -0500 [thread overview]
Message-ID: <cec7bb32-1a34-4c3c-8b8b-175d998003ef@huarp.harvard.edu> (raw)
In-Reply-To: <5748524.yeFs27NDWt@nimes>
[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]
On 11/10/2023 5:27 PM, Bruno Haible wrote:
> Norton Allen wrote:
>> 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.
> I disagree. I cited the relevant sentences from the standard.
This is the sentence you quoted that I am referring to:
> The srand function is not required to avoid data races with other
> calls to pseudo-random sequence generation functions. ..."
That is not the same as "... required never to avoid data races ...".
"not required" means the sentence is not specifying--not requiring--any
behavior, so you should not depend on the described behaviors.
>
> Other platforms (glibc, Android) avoid race conditions in rand()
> by locking. Which is compliant with the standard.
I'm not sure I understand what you're saying. Do they require the caller
to implement their own race-avoidance approach via locking, or is it
implemented within rand()?
As you point out, there is no race condition here, but it looks to me as
though the Cygwin strategy chooses to avoid race conditions by making
the rand() state be entirely private to each thread. As a result, the
call in rand_invocator_thread() acts as though no call to srand() has
occurred. You are suggesting that the thread should inherit the rand
state from the parent, which would certainly make the threads subject to
race conditions, even if the calls themselves were thread-safe. Which
value your thread gets would depend on how fast it ran relative to the
other threads. Unless there is language in the standard that says the
states should be shared, I don't see how the Cygwin approach violates
the standard.
That said, I am often wrong, and I'd be happy to have you point out my
misunderstanding.
next prev parent reply other threads:[~2023-11-11 16:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-10 20:19 Bruno Haible
2023-11-10 21:39 ` Norton Allen
2023-11-10 22:27 ` Bruno Haible
2023-11-11 16:50 ` Allen, Norton T. [this message]
2023-11-11 18:25 ` René Berber
2023-11-11 20:18 ` Allen, Norton T.
2023-11-13 14:17 ` Corinna Vinschen
2023-11-13 14:25 ` Bruno Haible
2023-11-13 14:38 ` Corinna Vinschen
2023-11-13 16:21 ` Corinna Vinschen
2023-11-13 16:44 ` [EXTERNAL] " Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2023-11-13 21:33 ` Bruno Haible
2023-11-13 22:14 ` Glenn Strauss
2023-11-14 10:20 ` Corinna Vinschen
2023-11-14 10:11 ` Corinna Vinschen
2023-11-14 11:52 ` Bruno Haible
2023-11-14 16:59 ` Corinna Vinschen
2023-11-14 18:06 ` Bruno Haible
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cec7bb32-1a34-4c3c-8b8b-175d998003ef@huarp.harvard.edu \
--to=allen@huarp.harvard.edu \
--cc=bruno@clisp.org \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).