From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2560 invoked from network); 4 Oct 2022 16:46:15 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 Oct 2022 16:46:15 -0000 Received: (qmail 15908 invoked by uid 550); 4 Oct 2022 16:46:12 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15873 invoked from network); 4 Oct 2022 16:46:10 -0000 Date: Tue, 4 Oct 2022 12:45:57 -0400 From: Rich Felker To: James Y Knight Cc: musl@lists.openwall.com Message-ID: <20221004164557.GO29905@brightrain.aerifal.cx> References: <20220919152937.GQ9709@brightrain.aerifal.cx> <20221003132615.GF2158779@port70.net> <20221003212705.GG2158779@port70.net> <20221003225416.GG29905@brightrain.aerifal.cx> <20221003230505.GH29905@brightrain.aerifal.cx> <2e77a700561a059e85daad5311306cfb@ispras.ru> <20221004141242.GL29905@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Illegal killlock skipping when transitioning to single-threaded state On Tue, Oct 04, 2022 at 12:24:14PM -0400, James Y Knight wrote: > On Tue, Oct 4, 2022 at 10:13 AM Rich Felker wrote: > > > If this is actually the case, it's disturbing that GCC does not seem > > to be getting it right either... > > > > The __sync_* builtins are legacy and were never particularly well-defined > -- especially for non-x86 platforms. (Note that they don't include atomic > load/store operations, which are effectively unnecessary on x86, but vital > on most other architectures). > > I would suggest that musl (and anyone else) really ought to migrate from > its homegrown atomics support to the standard C11 atomic memory model, > which _is_ well-defined and extensively studied. Such a migration will > certainly be a Project, of course... We do not use the __sync builtins. Atomics in musl are implemented entirely in asm, because the compilers do not get theirs right and do not support the runtime selection of methods necessary for some of the archs we support (especially 32-bit arm and sh). The atomics in musl implement the "POSIX memory model" which is much simpler to understand and less error-prone than the C11 one (with the tradeoff being that it admits a lot less optimization for performance), and is a valid implementation choice for the C11 one. It has only one relationship, "synchronizes memory", that all synchronization primitives and atomics entail. The migration that might happen at some point is using a weaker model for the C11 synchronization primitives and possibly for the POSIX ones in the future if POSIX adopts a weaker model. Of course we could also do this for our own implementation-internal locks, independent of whether POSIX makes any changes, but among those the only ones that have any significant effect on performance are the ones in malloc. It's likely that mallocng could benefit a lot from relaxed-order atomics on the free bitmasks and weaker acquire/release semantics on the malloc lock. But this would only help archs where weaker forms are available. Rich