[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 24 Jul 2015 00:21:10 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: implement stdatomic.h library interface
Hello,
Am Donnerstag, den 23.07.2015, 14:14 +0200 schrieb Joakim Sindholt:
> > Looking back on this, I think that we had a bit of a wrong focus,
> > then. The point for musl wouldn't necessarily be to provide the
> > <stdatomic.h> header itself, but the stub functions that are needed if
> > the compiler isn't able to inline all operations.
>
> I was mainly motivated by the __c11_atomic primitives in clang being
> added in 3.1 but the header not being there until 3.6. I still think
> it's worthwhile to provide stdatomic.h in musl, just as it provides
> stddef.h.
Ok, I see.
I think that this situation is relatively easy to detect (e.g testing
for __ATOMIC_RELAXED) and we can then provide a replacement. But my
idea is that generally, if the compiler provides a <stdatomic.h>, we
should use that. These will probably improve in time, we shouldn't cut
off from that.
> > Since I needed it, now, I just went for it and implemented it. For the
> > moment this isn't integrated to musl but standalone, and for a proper
> > integration into musl I'd still have some work to do.
>
> You (re)implemented all the libgcc/compiler-rt atomic symbols?
We'll see if I have them all, but it is less difficult than it
sounds. There is a lot of repetition.
> > At the moment I see three principal possibilities for improvement with
> > atomics in musl:
> >
> > (1) Provide the library interfaces that gcc >= 4.8 and clang > 3.6 (?)
> > need. The interface is well documented, so let's just do it.
>
> GCC has __atomic in 4.7 (_Atomic and header added in 4.9 IIRC)
> Clang has __c11_atomic in 3.1 (header added in 3.6)
I wasn't aware of 4.7 already implementing that stuff. My current
strategy is
if __ATOMIC_RELAXED is there,
if there is __clang__ use for __c11_atomic
else use __atomic
else use __sync
> > (2) Provide an interface to atomics for compilers that don't have it
> > yet. This can be done more or less easily up to some limits for
> > all compilers that implement the __sync builtins. gcc 4.8 is a bit
> > special since it implements the atomic operations but not the type
> > qualification.
> >
> > For compilers that don't have __sync or __atomic we could provide
> > a minimal interface with lock-free _Atomic(int), _Atomic(void*)
> > and atomic_flag, say.
> >
> > The limits for these platforms would be that code could only use
> > the _Atomic(bla) specification for the types and macro calls to
> > act upon them. But since for pre-C11 compilers this is just an
> > extension, that would be a start.
>
> I suppose the real question here is how you're going to implement it
> macro-wise to map to actual C functions. I've never really managed to
> come up with a proper solution. I would love to have it though.
For compilers that implement the __atomic.. or __c11_atomic.. this is
not very difficult. Basically the compilers are providing all the
logic to differentiate the cases.
For the __sync... interfaces I am currently doing that. This uses
__builtin_choose_expr as a poor-man's _Generic to separate the special
cases for the size. Its a bit ugly, but does the job.
(And it also forces the choice expression to be compile time constant,
so the effects of multiple evaluation in __typeof__ can be mastered.)
> What I don't understand is why it's seen as a necessity to re-implement
> compiler-specific functionality. Musl doesn't provide umoddi3 or other
> libgcc symbols, so why the stdatomic internals? Are you trying to
> compile without a compiler runtime library?
Same reason as your motivation for having a working <stdatomic.h> for
previous versions of clang. It would be equally nice to have such a
thing, even if the support would only partial (only the functions, not
operators) for older gcc's.
Many people will be stuck with older compilers for years. This would
offer an easy an portable way to use that feature already, the same
way as it is possible to use C11 threads without having a compiler
that is fully compliant to C11.
> I get that it could be useful to have instead of musl's current internal
> atomics but IMO only if it actually saves you the work of implementing
> the atomic primitives in the first place.
Implementing just a frontend to atomics by dispatching them to
__sync/__atomic/__c11 builtins is much, much simpler than doing that
on an per-arch base, I think. Also, it might enable us to use finer
memory models for certain operations (well, we'll see) and to profit
from improvements that are done on the compiler side.
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.
