[cfe-commits] [PATCH] atomic operation builtins, part 1
amacleod at redhat.com
Thu Oct 13 06:22:19 PDT 2011
On 10/12/2011 09:40 PM, John McCall wrote:
> On Oct 12, 2011, at 6:27 PM, Eli Friedman wrote:
>> On Wed, Oct 12, 2011 at 6:06 PM, John McCall<rjmccall at apple.com> wrote:
>>> On Oct 12, 2011, at 2:54 PM, Andrew MacLeod wrote:
>>>> I'm still not sure I see how it matters. Nothing should ever access or change that padding field in an unfriendly way since it is always part of the atomic word that is load/stored, exchanged or compare_exchanged. Those are the only 4 ways to access the memory. All the fetch_op's only operate on full integral values, so thats not a concern. Compare_exchange is the only one which it could be affected, and it requires that the 'expected' value be from an atomic load or exchange…
>>> I wasn't aware of that. That's really a very strange constraint — why is it illegal to independently assemble a value that I expect might be in an atomic variable?
>> The standard doesn't make any guarantees about the layout of
>> std::atomic<T>; how exactly could you manipulate the bits of an
>> std::atomic<T> in a cross-platform manner?
> You couldn't, but that's not what I said. I'm saying that it's strange
> that the expected value of a compare& exchange is apparently
> not permitted to be a T that I've constructed in an arbitrary way;
> it has to be a T that I've read with an atomic load or exchange.
Actually, the generic interface breaks if the atomic type is not the
same size as the base type.
void __atomic_exchange (size_t size, void *ptr, void *expected, void
in reality, from GCC's point of view, it currently doesn't distinguish
an atomic type from the base type, it just sees:
void __atomic_exchange(T *ptr, T *expected, T *desired, ...)
if 'expected' and 'desired' were different sizes than 'ptr', we'd need
another size parameter and have to deal with padding code, and I'm not
prepared to go down that road just yet.
So my current GCC plan for this release is to always keep stuff the same
size... if its a 3 byte object, its 3 bytes and will call the generic
routine. I think arbitrary size support is something that will always be
It might be worth considering a helpful warning flag that would indicate
in this case that "4 byte objects are lock free on this target, increase
the size of your object if you would like to take advantage of it."
We can add additional interface(s) in the next release to satisfy
whatever long term goals are decided upon before then, something like
void __atomic_exchange(size_t atomic_size, size_t size, void *
atomic_ptr, void * expected, void *desired,...)
which can included padded atomics or whatever else we arrive at. There
clearly hasn't been enough thought put into the long term design of this
to commit to anything yet.
And with C not properly defined yet, I doubt anyone is locking their
system future into this release.
If the language allows an arbitrary class to be atomic, its not fair to
issue an error if its not lock free. There is nothing that says an
atomic class has to be lock free, and it even provides a method to ask
if its lock free.. I think there is a large class of consumers of the
language that are going to think its pretty useless if I cant just say
'class employee' is atomic and have it work. Lawrence had to convince
me that a locked implementation should reside in an external library
rather than be provided by the language. I do intend to provide a
simple buildable library from the old libstdc++ locked implementation so
that joe blow user (or myself) can resolve his external routines if need be.
Are there any issues with those 2 points?
More information about the cfe-commits