[cfe-dev] atomic intrinsics

[Howard Hinnant]

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:

> The function atomic_is_lock_free (29.6) indicates whether the object is lock-free. In any given program execution, the result of the lock-free query shall be consistent for all pointers of the same type.

This part of the atomic_is_lock_free specification is separated from the rest of the atomic_is_lock_free specification by 10 pages because putting the specification all in one place would be just what the reader expected. ;-)

-Howard