From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9110 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: atomic.h cleanup Date: Thu, 14 Jan 2016 17:12:57 -0500 Message-ID: <20160114221257.GS238@brightrain.aerifal.cx> References: <20160110122139.GF2016@debian> <20160110165718.GR238@brightrain.aerifal.cx> <20160110173509.GG2016@debian> <20160111163544.GI2016@debian> <1452532349.28095.10.camel@inria.fr> <20160111190356.GA13558@port70.net> <1452545810.28095.12.camel@inria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1452809603 31417 80.91.229.3 (14 Jan 2016 22:13:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Jan 2016 22:13:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9123-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 14 23:13:13 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aJq8n-0007Ri-Bg for gllmg-musl@m.gmane.org; Thu, 14 Jan 2016 23:13:13 +0100 Original-Received: (qmail 32504 invoked by uid 550); 14 Jan 2016 22:13:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 32474 invoked from network); 14 Jan 2016 22:13:09 -0000 Content-Disposition: inline In-Reply-To: <1452545810.28095.12.camel@inria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9110 Archived-At: On Mon, Jan 11, 2016 at 09:56:50PM +0100, Jens Gustedt wrote: > Am Montag, den 11.01.2016, 20:03 +0100 schrieb Szabolcs Nagy: > > * Jens Gustedt [2016-01-11 18:12:29 +0100]: > > > Am Montag, den 11.01.2016, 17:35 +0100 schrieb Markus Wichmann: > > > > OTOH, maybe we simply shouldn't write synchronisation primitives > > > > ourselves and instead use the ones provided by GCC (and let other > > > > compilers suck on a salty sausage, if they don't support those > > > > primitives). > > > > > > I think on the long run we should use C11 atomics and leave the dirty > > > work to the compiler writers. To my experience they do good work with > > > that now, the assembler they produce looks nice. > > > > > > > yes but old compilers had various bugs on various targets. > > > > > My stdatomic library is sitting there, ready to integrate into > > > musl. It solves the problem of backwards compatibility for all > > > compilers that that implement the __sync builtins. (gcc and clang with > > > very old version numbers.) > > > > > > > i think simpler compilers like pcc, cparser, tcc > > dont implement that. > > > > if musl moves to compiler builtins then i'd > > like to have a possibility to compile atomic > > primitives as a separate tu > > In a sense, stdatomic has that already. It also implements the atomic > operations as fallback functions, for the case that the compiler isn't > able to synthesise the operation. > > But you are right, support for those simpler compilers then would mean > that we'd have to maintain stubs, at least for the most commonly used > 4 byte operations. There are already multiple reasons we don't use the compiler's atomics, either directly or indirectly via stdatomic.h. They're not supported in some old/alternative compilers, they generate highly suboptimal code even on modern compilers for some important archs (e.g. ARM), and they fail to properly support archs where it's necessary to make a runtime choice of which atomic code paths to use in order to achieve safe/correct behavior. With the atomics overhaul I am planning to have an option (selected by the arch headers, not the user) to use __sync_* as the backend for atomics, which will ease porting to new archs where it already works correctly on all compilers that support the arch. > > > Last time I looked, all usages but one of atomic operations in musl > > > are clean. If an atomic operation is used for a data a some point, > > > atomic operations are used in all other places. So moving to > > > _Atomic(int) would be a option. (Basically this would be `volatile > > > int*` => `_Atomic(int)`, IIRC). > > oops I meant `volatile int*` => `_Atomic(int)*` > > > pthread_once_t and pthread_spinlock_t are > > publicly visibles type (without volatile and > > _Atomic) > > > > i dont think we can fix those without abi > > change. > > This is really a question what ABI means in this case. The width, > alignment and representation of the `int` would stay the same, we > would just internally (to the library implementation) interpret it as > _Atomic(int). >From a C++ perspective ABI certainly includes the type that will appear in mangled function names. This is the main motivation for not changing types like this. Of course LTO could also break when formal types don't match. > Also it seems that we do such a re-interpretation already with > `volatile`. One interpretation of the standard says that the object > itself has to be `volatile`, just casting a pointer to `volatile int*` > doesn't inhibit optimizations. GCC explicitly interprets it the other way, and documents it as such. If we want to deal with compilers that don't provide such a guarantee, and for which the accesses could break, we probably need an explicit load construct in asm... But this seems like a low priorit and I'm happy to wait to address it unless/until real-world problems seem likely. For this reason it would be nice to document the assumption, however, as Szabolcs Nagy suggested we do for issues like this. Rich