[v3] updated atomic configury
Andrew MacLeod
amacleod@redhat.com
Tue Nov 22 04:02:00 GMT 2011
On 11/21/2011 09:29 PM, Benjamin Kosnik wrote:
> Here's the first step in making the libstdc++ atomic configure bits into
> something that makes more sense. This consolidates the builtin parts of
> the configury, such that builtins mean C++11 atomics, not C++11 atomics
> mixed with pre-C++11 atomics.
>
> I think this is mostly right, modulo my logic on the equivalency of
> ATOMIC_INT_LOCK_FREE == _GLIBCXX_ATOMIC_BUILTINS_4. This is something
> that should hold, IMHO.
>
Well, I guess it should. _GLIBCXX_ATOMIC_BUILTINS_4 is defined as an
'int' in the configure file, even if an 'int' isn't 4 bytes for some
target. So that should work for backwards compatibility.
If you really want it to be 4 bytes you would have to use
__atomic_always_lock_free (4) then its not dependent on the sizeof(int).
> I was expecting
> the C++11 macros for lock-free properties, ie ATOMIC_BOOL_LOCK_FREE to
> be either 0, 1, 2, and to be able to use them like:
>
> #if (ATOMIC_INT_LOCK_FREE> 1)
> // yes, cool, yeah!
> #endif
>
> But this doesn't seem to work. And what I have in this patch, which is
That should work. The __atomic_always_lock_free(X) does fold to a
compile time constant... but perhaps it doesn't fold early enough to be
used by the preprocessor?
oh, I see you changed it to:
#define __LOCK_FREE_PROPERTY(T) (__atomic_always_lock_free(sizeof(T), 0) ? 2 : __atomic_is_lock_free(sizeof(T)))
The problem with that is that under the new regime, if an atomic size is
not *always* lock free, then __atomic_is_lock_free() becomes a runtime
libary call. So this definition you have will resolve to either a 2,
or a runtime function call.
All we can now tell at compile time is whether something is a 2 or
not. __atomic_always_lock_free() was created to be the compile time
version that never resolves to a library call, so you can set the macro
to either 2 if its true, or 1 if its false like I had before. we will
never, ever, set the macro to a value of 0.
Anyway, it looks like __atomic_always_lock_free doesn't fold early
enough to be usable by the preprocessor like that even with my earlier
version. ugg. I think I can get something defined in cpp-builtins that
we can use. We're going to need it for C1x next release anyway.
Should be ready to try tomorrow sometime.
Andrew
More information about the Libstdc++
mailing list