X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B45D9384978B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1699913684;
	bh=T1JtiLWeXvpbJu1b9EIZejsoAl2M9Lit4P87KYET7mQ=;
	h=Date:To:Cc:Subject:References:In-Reply-To:List-Id:
	 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	 From:Reply-To:From;
	b=tAeTT27dfqjiGzGkU9oiZibLfQlesCHZcqe2hOyLRaD9/c9mkimXruTu2M6c5IcjD
	 jBeWEuqY1exQls1fReijMRc11KFjNOZaolTwil+3oBrN5lOJ2na186iJ6qGUkns75K
	 sdSbQ4gHw3WMBi1WHoE812jBHQDYoYj+unpBuKls=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 620633858C33
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 620633858C33
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699913668; cv=none;
 b=RrznEpeB05mxsdb8UMqpnXNIjx5er5eX2IdDYutyoF06yDCzScXJVzw+WEycJ/CSNkxsAWE0ckbT1zEPFWRaMF89f3NfopLH2tU9/TKqdqRhZyqXNB9kiUp7IgFt6YtpJW8a1gj1Qa2KCPHBg17aI9oJDVqtQa74xkXz5jOF2X8=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1699913668; c=relaxed/simple;
 bh=Xm3ROHutP47f2hEq1LouE1GHIQBwqGXwQkGU6rudjrA=;
 h=Date:From:To:Subject:Message-ID:MIME-Version;
 b=uJo+aJlrmvUZVfNes1IOI22O9x3UXz0rFXoN+p3UD9f/c+P0aW0E0bNx5RdtNiQpzAN9giHl4aX+q/I6yR19uEnWNEo/CGO1lLPJtmvexd4BEWL1Z6n+YZuRo9/NRScMUqolBt/ToaoD1cij42B+lFrwG+X79CVNS+doLbL9Ogo=
ARC-Authentication-Results: i=1; server2.sourceware.org
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-Spam-Language: en
X-Spam-Relay-Country: 
X-Spam-DCC: B=; R=smtp1.atof.net 1206; Body=1 Fuz1=1 Fuz2=1
X-Spam-RBL: 
X-Spam-PYZOR: Reported 0 times.
Date: Mon, 13 Nov 2023 17:14:18 -0500
To: Bruno Haible <bruno AT clisp DOT org>
Cc: newlib AT sourceware DOT org, cygwin AT cygwin DOT com
Subject: Re: rand is not ISO C compliant in Cygwin
Message-ID: <ZVKfuuI8rryAwszD@xps13>
References: <9938355 DOT c9vzh5UkMf AT nimes> <ZVI06HnJE+r1CwFB AT calimero DOT vinschen DOT de>
 <ZVJM7g9smHGMN7QH AT calimero DOT vinschen DOT de> <4205183 DOT RD5H4TdPZm AT nimes>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4205183.RD5H4TdPZm@nimes>
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 SPF_HELO_NONE, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Glenn Strauss via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Glenn Strauss <gs-cygwin DOT com AT gluelogic DOT com>
Content-Type: text/plain; charset="iso-8859-1"
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id 3ADMEkJ4031704

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