Re: [v3] updated atomic configury

[Andrew MacLeod <amacleod at redhat dot com>]

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