X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ED214385F026
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1699957242;
	bh=D30yO8TaHkSBTj3QFwadrCT6nRLFd8KSdlVQeTDvOV4=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=sPjJ0tSpxZoMbJAX+NPi9OXxyuRnEZC5p+fAnO61Ys5CyXA71sI5tlUStdm3RgOzJ
	 CRK5XFZShHkkN7Fga2odMD/JkXUHEEDfxk7bNUaB8ZT6xgRwEo33d23Q7vOscvTPnc
	 NiNFFxg7dSFPWiFV2eCDX9pfBo2ZeOPq1WMTp9+U=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 155163858C20
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 155163858C20
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699957229; cv=none;
 b=DFfebN5w6iqdub/gKVJ3qifoT/k5p14OEVpUheXSjyhM9rcd4tM3eGJRciyWSmoXZtle5YdT6aouxMch/xvx1ML2Srf37HCxYhXqgTZaeEuwXyvvzi/8AFECohIsYm7OECxBTxcg9f9i7Bn7pZTTRUzkiYvSr1WIWJ8RqEN6nlI=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1699957229; c=relaxed/simple;
 bh=lHotkTKJ5iRl7rcCRQ3n2s36qwCzPeB6VqAZM9Qd1Cw=;
 h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;
 b=RdKQbu6294njUAFD4vgeADrNYsZ7cBESf4ItP+4v8tK3Cxsa1P6jYcvzLGd9306xtP/ZHl6noFj8nikvoSEI0w+tAAr1vRPcARblUXZbXuiGzuUC3f278X3+qwphuME76yaS/OMvZL/GnYW7mITy9nLuJBMq8L++Vxrx8vmglo8=
ARC-Authentication-Results: i=1; server2.sourceware.org
X-MC-Unique: u9Lv6wr5N8iNYyUqLN55bg-1
Date: Tue, 14 Nov 2023 11:20:24 +0100
To: Glenn Strauss <gs-cygwin DOT com AT gluelogic DOT com>
Subject: Re: rand is not ISO C compliant in Cygwin
Message-ID: <ZVNJ6MRORt6uxq78@calimero.vinschen.de>
Mail-Followup-To: Glenn Strauss <gs-cygwin DOT com AT gluelogic DOT com>,
 Bruno Haible <bruno AT clisp DOT org>, newlib AT sourceware DOT org,
 cygwin AT cygwin DOT com
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>
 <ZVKfuuI8rryAwszD AT xps13>
MIME-Version: 1.0
In-Reply-To: <ZVKfuuI8rryAwszD@xps13>
X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.9
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Disposition: inline
X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
 DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE,
 RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
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: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: newlib AT sourceware DOT org
Cc: Corinna Vinschen <vinschen AT redhat DOT com>, Bruno Haible <bruno AT clisp DOT org>,
        newlib AT sourceware DOT org, cygwin AT cygwin DOT com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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>

On Nov 13 17:14, Glenn Strauss wrote:
> On Mon, Nov 13, 2023 at 10:33:48PM +0100, Bruno Haible via Cygwin wrote:
> > 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().

That's a good common sense argument for changing rand() to use a global
state.


Corinna


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