[cfe-dev] atomic intrinsics

Howard Hinnant hhinnant at apple.com
Mon Oct 18 09:11:55 PDT 2010


On Oct 16, 2010, at 9:34 AM, Howard Hinnant wrote:

> On Oct 16, 2010, at 9:21 AM, Sebastian Redl wrote:
> 
>> 
>> On 16.10.2010, at 03:05, John McCall wrote:
>> 
>>> On Oct 15, 2010, at 5:03 PM, Howard Hinnant wrote:
>>>> Thanks for looking at this John.
>>>> 
>>>> On Oct 15, 2010, at 7:21 PM, John McCall wrote:
>>>> 
>>>>> On Oct 7, 2010, at 5:30 PM, Howard Hinnant wrote:
>>>>>> I see what you mean.  I'll mention this in the design doc.  I believe it will be an issue for any design we choose (A, B, or C).
>>>>> 
>>>>> 
>>>>> After some thought, I think I personally prefer proposal A, slightly modified such that __atomic_is_lock_free is a pseudofunction like __is_pod().
>>>> 
>>>> I see, like:
>>>> 
>>>> bool __atomic_is_lock_free(type);
>>>> 
>>>> ?
>>> 
>>> That's what I was thinking.
>> 
>> Is that sufficient? The library spec contains a per-object is_lock_free(), presumably so that it can return false for unaligned objects. Are we confident that all such cases can be resolved in the library, so that the only query to the compiler needs to be about the underlying type?
> 
> Good question.  I think we're ok on the C++ side.  I don't know about the C side.  In N3126 (the current draft) 29.4 [atomics.lockfree]/2 says:

I checked with Lawrence Crowl concerning the C side.  The C spec currently says that different invocations of atomic_is_lock_free for the same pointer type may return different results.  Lawrence tells me that the C spec is based on an old C++ spec and is due to be changed to be consistent with C++.  Therefore I believe we're good to go with bool __atomic_is_lock_free(type).

I've updated Design A under:

http://libcxx.llvm.org/atomic_design.html

with the above change, and a few more details.  I'm hearing consensus on Design A.  If you feel differently please speak up.  I plan on commencing work on libc++'s <atomic> immediately, assuming Design A.

One question about Design A that has yet to be discussed is the possible defaulting of memory orderings in the intrinsics.  This defaulting, if it exists, is described at the very bottom of:

http://libcxx.llvm.org/atomic_design_a.html

I have no strong feeling either way.  I can easily live with or without the memory order defaults.  But I should either remove the "If desired" from the description (mandating the defaults), or remove the description of the defaults altogether (banning them).  Please weigh in with your opinions.

Thanks,
Howard





More information about the cfe-dev mailing list