Re: atomic.h cleanup

[Szabolcs Nagy <nsz@port70.net>]

* 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

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

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.