[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1452545810.28095.12.camel@inria.fr>
Date: Mon, 11 Jan 2016 21:56:50 +0100
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: atomic.h cleanup
Am Montag, den 11.01.2016, 20:03 +0100 schrieb Szabolcs Nagy:
> * Jens Gustedt <jens.gustedt@...ia.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.
> > 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).
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.
Jens
--
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536 ::
:: :::::::::::::::::::::: gsm France : +33 651400183 ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
