On 10/12/2011 02:49 AM, Jeffrey Yasskin wrote: > On Tue, Oct 11, 2011 at 7:53 PM, Andrew MacLeod<[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
