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

[Andrew MacLeod]

On 10/12/2011 01:57 PM, John McCall wrote:
> On Oct 12, 2011, at 9:03 AM, Jeffrey Yasskin wrote:
>> On Wed, Oct 12, 2011 at 6:31 AM, Andrew MacLeod<amacleod at redhat.com>  wrote:
>>> - language atomic types up to 16 bytes should be padded to an appropriate
>>> size, and aligned properly.
>>> - if memory matching one of the 5 'optimized' sizes isn't aligned properly,
>>> results are undefined.
>>> - if the size does not match one of the 5 specific routines, then the
>>> library generic ABI can handle it.  There's no alignment guarantees, so I
>>> presume it would end up being a locked implementation using hash tables and
>>> addresses or something.
>> The ABI library needs to demand alignment guarantees, or have them
>> passed in, or it won't be able to support larger lock-free sizes on
>> new architectures.
> How aggressive are you suggesting we be about this?  If I make this type atomic:
>    struct { float values[5]; };
> do we really increase its size and alignment up to 32 bytes in the wild hope that the architecture will add 32-byte atomics someday?  If so, what's the limit?  If not, why is 16 the limit?
>
I gather thats the direction he leaning...

My own opinion is we should probably just allow whatever size is 
desired, and if it doesn't map to one of the supported lock-free sizes, 
the the library can do with it whatever it wants.. probably a locked 
implementation.  I would tend to make the compilers round atomic objects 
up to 4 and 8, and possibly even 16 since those sizes have a decent 
chance of being lock free, and avoiding any calls to a library.  I doubt 
we'll see large arrays of large atomic objects.   (famous last words). 
      for  objects where it matters, we can probably detect alignment 
after the fact by looking at the pointer value... you should be able to 
tell if a 32 byte object pointer is pointing to a 32 byte boundry or not.

The compiler built-ins can always be called directly with arbitrary 
sized objects, so it would be good for the generic routine to handle it 
rather than artificially restrict it.

> Honestly, I don't think future-proofing against arbitrary new atomic instructions really makes any sense.  Even going up to 16 bytes (on architectures where that can't be done lock-free now) worries me a bit.
>
> Rounding up also worries me, since the user has no control over the padding bytes, but they can still cause spurious failures on, say, compare-and-swap.

If the padding is under control of the 'atomic' keyword for the type, 
then we have complete control over those padding bytes. Regardless of 
what junk might be in them, they are part of the atomic data structure 
and the only way to access them is through a full atomic access. Its 
like adding another user field to the structure and not setting it. It 
shouldn't cause spurious failures.

Andrew