[cfe-commits] [PATCH] atomic operation builtins, part 1

[Andrew MacLeod]

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.

1)
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 
*desired,...);

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 
needed.

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.

2)
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?

Andrew