Re: atomic.h cleanup

[Rich Felker <dalias@libc.org>]

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 <jens.gustedt@inria.fr> [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