DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 081853858039
Message-ID: <cec7bb32-1a34-4c3c-8b8b-175d998003ef@huarp.harvard.edu>
Date: Sat, 11 Nov 2023 11:50:30 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: rand is not ISO C compliant in Cygwin
To: Bruno Haible <bruno@clisp.org>, cygwin@cygwin.com
References: <9938355.c9vzh5UkMf@nimes>
 <e099714b-9820-4647-ba40-9db5e471e9aa@huarp.harvard.edu>
 <5748524.yeFs27NDWt@nimes>
Content-Language: en-US
In-Reply-To: <5748524.yeFs27NDWt@nimes>
Precedence: list
From: "Allen, Norton T. via Cygwin" <cygwin@cygwin.com>
Reply-To: "Allen, Norton T." <allen@huarp.harvard.edu>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>
Content-Transfer-Encoding: 8bit

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.

-- 
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