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

[Andrew MacLeod]

On 10/12/2011 02:49 AM, Jeffrey Yasskin wrote:
> On Tue, Oct 11, 2011 at 7:53 PM, Andrew MacLeod<amacleod at redhat.com>  wrote:
>>    I'm not even sure how to do a 3 byte lock free atomic write short of load,
>> mask, compare and swap loop. It reeks of the bitfield data race crud.  Let
>> the library take care of it, or maybe even dissallow it...   thoughts?  My
>> first instinct is to just pass it on to the library to handle...
> Given:
>
> struct WeirdSize {
>    char space[3];
> };
>
> My thought was that sizeof(atomic<WeirdSize>) should ==4. C++11 says,
> "The representation of an atomic specialization need not have the same
> size as its corresponding argument type. Specializations should have
> the same size whenever possible, as this reduces the effort required
> to port existing code." [atomics.types.generic]p9, which recommends
> against this, but allows it.
>
> I think it's reasonable for either the C++ library or _Atomic(T) to do
> this rounding, and for the atomic intrinsics to either demand
> normal-sized arguments (be undefined/error if not) or pass
> unusual-size arguments to the ABI library, but I don't have strong
> opinions about this.
>

Yes, I was thinking that such a  struct would be 4 bytes, but of course 
it is only 3.   I agree,  _Atomic(T) should round it to 4 bytes to 
attempt to use lock free routines, as should any c++ atomic class.
so I'd say:

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

I'd consider simply banning sizes which are not either one of the 5 
basics, or some multiple of target word size for those greater than 16, 
but I don't think the implementation in the library will really care if 
its 3 bytes or 300 bytes, so the restriction might be artificial for no 
really good reason.

I also am a bit ambivalent about it, but lean towards allowing arbitrary 
sizes.

Andrew