[cfe-dev] atomic intrinsics

[Howard Hinnant]

On Oct 7, 2010, at 7:57 PM, Jeffrey Yasskin wrote:

> On Thu, Oct 7, 2010 at 7:26 AM, Howard Hinnant <hhinnant at apple.com> wrote:
>> Thanks Jeffrey, comments below:
>> 
>> On Oct 7, 2010, at 4:58 AM, Jeffrey Yasskin wrote:
>>> * I'm not sure if you want this in the API doc, but the choice of
>>> mutex vs. lock-free instructions to implement each size/type is an ABI
>>> decision, and that needs to be noted somewhere for each target. That
>>> is, if clang-2.9 implements the 16-byte atomic by calling out to
>>> compiler-rt, which uses a spinlock to make it atomic, and then
>>> clang-2.10 implements it by using the cmpxchg16b instruction, that's
>>> an ABI change. To avoid ABI changes, we'd need to implement all the
>>> atomics up to the largest platform-supported size using instructions
>>> in the first version that supports them at all.
>> 
>> I haven't taken action yet on this as I'm not yet sure how to modify the design doc.  Your point reminded me of something else:
>> 
>> The library has functions that look like:
>> 
>>    bool atomic_is_lock_free(const volatile type*);
>>    bool atomic_is_lock_free(const atomic_itype*);
>> 
>> To implement this, the library must be able to ask the compiler this question in some way.  So perhaps I should add to the list of intrinsics:
>> 
>>    bool __atomic_is_lock_free(const type*);  // volatile implied by comment just added to A
>> 
>> Does the existence of this intrinsic mitigate your ABI concern?  I.e. if the client cares about this ABI, he has to query it.
> 
> I don't think it mitigates the ABI concern, although I could be wrong.
> Say you have:
> 
> TU1.cc
> -----------
> atomic<long long> A;
> int foo() { return A.load(); }
> 
> TU2.cc
> -----------
> extern atomic<long long> A;
> void bar() { A.store(3); }
> 
> 
> How would I use __atomic_is_lock_free() to make those link together
> thread-safely if one's compiled with a version where long long is lock
> free, and the other is compiled with a version where it's locked?

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

-Howard