From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) by sourceware.org (Postfix) with ESMTPS id 271913858D37 for ; Mon, 13 Nov 2023 17:34:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 271913858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=Shaw.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=shaw.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 271913858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=3.97.99.33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699896886; cv=none; b=JK/utzM2wbQQzR1yWtbeqFXlj0NM+bfZs0PvdvihZI666sJJpcMAh0aq/Z6BltxHOPOW1VjxLYweH4BU58a5gRWrfs6VEh51TRAfTs8WyH6e02zlBZlu9+vlEQLq4nZxY3GoMUeCd/4/7NvzXe5PQnWxdSO7j6EQJHZfXfBSy0c= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699896886; c=relaxed/simple; bh=mKI49SKh9MfWqe+UmEpAnSCd72iqTHq5Zd7lbk8qmKc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=HLtfPXfbK8yB7RuLyY3API1RG43s8tNp2jyzXBE7ZVloEck75jNjgTsLSM+14BY4lCMFXGRlDETuaW2vPNsRRUaM7uAYGP5YJ7iRsN3TlDZLlrndPLfszIYZwFBN+vEFnYJoGhEMKyMjM9a55mWirhozCXVLeXbuc3FXIPMaZa4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTPS id 2Z2pr44LHB0n02apgrafCK; Mon, 13 Nov 2023 17:34:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shaw.ca; s=s20180605; t=1699896884; bh=mKI49SKh9MfWqe+UmEpAnSCd72iqTHq5Zd7lbk8qmKc=; h=Date:Reply-To:Subject:To:References:Cc:From:In-Reply-To; b=nraKRv+n/venDq+LxVaMAtrMcP/tI/rg2ZbKO5qNZGJvpyCgBbGN2UCX7vvIugkhk yKTMeGvYsZqPlf6+u4m8IT69xQN5AecISsmftrjPFBbr0PEvlqH5sBRaYqnp9hTH3+ VzbBXSF776JsIiFkm7tF/iWsm+anj1lF8Nmgkm2wI9uEeOkVdCh3/Pnysyhg9sm9GV 2QRqWMyoLWDXi3KGYuDw84O037mAtkvCqc2MIMWN8v7VsI7sIwE3MYHEX4oVc6p66J xJYV/rNIT1Z4ZgZ3uHYkesIDh25gvdj2bdYKmIfuWzXZn3RCtsk8LeRBF21pDhN5lY kvzl/bcRdJjVQ== Received: from [10.0.0.5] ([184.64.102.149]) by cmsmtp with ESMTP id 2apgrihNkDqGY2apgrczQO; Mon, 13 Nov 2023 17:34:44 +0000 X-Authority-Analysis: v=2.4 cv=Cousz10D c=1 sm=1 tr=0 ts=65525e34 a=DxHlV3/gbUaP7LOF0QAmaA==:117 a=DxHlV3/gbUaP7LOF0QAmaA==:17 a=IkcTkHD0fZMA:10 a=PxpbvmigVv2tRuUqSXQA:9 a=QEXdDO2ut3YA:10 Message-ID: Date: Mon, 13 Nov 2023 10:34:43 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: cygwin@cygwin.com Subject: Re: random is not multithread-safe in Cygwin Content-Language: en-CA To: cygwin@cygwin.com References: <3811044.57xzQst1vy@nimes> Cc: Bruno Haible From: Brian Inglis Organization: Inglis In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfK0twq5HwM0xPtYVo/BkA+lWi6dJLQ/fkzT4EFGoNB4BcJ5+wN2ZYA9O1XN2o2s2gP0MPioRvD1ABVgGQ7A4YZPvuJLeBbfx8qEuUJNc4/QE5+AbG60p Uy7iVfb05fEorNR5GE6+efSlbOKRANLHy+7bqETSX8WXrtLRNLI7WFAfGH/0N0LC17HlplKEHxELD3l0l99j0kRAoKziUyD7ioI= X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,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 List-Id: On 2023-11-13 09:12, Corinna Vinschen via Cygwin wrote: > On Nov 10 17:19, Bruno Haible via Cygwin wrote: >> The function 'random' is, unlike 'rand', not marked as not MT-safe in POSIX >> [1][2]. Thus it must be multithread-safe [3]: >> "Each function defined in the System Interfaces volume of POSIX.1-2017 >> is thread-safe unless explicitly stated otherwise." >> And indeed glibc, musl libc, AIX, Android, and even NetBSD implement it in a >> multithread-safe way. > Our code is from FreeBSD, originally. I checked the latest code from > FreeBSD. It doesn't lock anything in random() and generates the same > error when running the same test app. > Why is that ok for FreeBSD? It appears that random(3) is intended to provide a single random series during execution of a program with simple needs; behaviour is not reproducible when threaded, says POSIX, newlib, and Linux (below). From POSIX The Open Group Base Specifications Issue 7, 2018 edition IEEE Std 1003.1-2017 Volume 2: System Interfaces and initstate(3p) to which random(3p) refers and defers but does not link or .so: "NAME random — generate pseudo‐random number SYNOPSIS #include long random(void); DESCRIPTION Refer to initstate()." * That's all folks! "NAME initstate, random, setstate, srandom - pseudo-random number functions ... APPLICATION USAGE ... Threaded applications should use erand48(), nrand48(), or jrand48() instead of random() when an independent random number sequence in multiple threads is required." From newlib: "NAME random, srandom - pseudo-random numbers ... NOTES random and srandom are unsafe for multi-threaded applications. _XOPEN_SOURCE may be any value >= 500. PORTABILITY random is required by XSI. This implementation uses the same algorithm as rand." * Newlib, and presumably FreeBSD, do not support initstate, setstate, or > 8 (for amd64/x86_64) bytes state. From man-pages-linux random(3): "CAVEATS ... The random() function should not be used in multithreaded programs where reproducible behavior is required. Use random_r(3) for that purpose." * As usual, random_r(3) requires the caller to provide an initialized state vector buffer (of 8-256 bytes), allowing the caller to decide the amount of randomness and scope of the random series, and possibly call initstate_r(3), to control the seed. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry