[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Jul 2015 14:14:15 +0200
From: Joakim Sindholt <opensource@...sha.com>
To: musl@...ts.openwall.com
Subject: Re: implement stdatomic.h library interface
On Thu, 2015-07-23 at 11:58 +0200, Jens Gustedt wrote:
> Hello,
> about half a year ago well already discussed this, and at that time
> Joakim had a proposal for an implementation.
>
> 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.
> 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?
> 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)
> (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.
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?
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.
-- Joakim
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.
