[cfe-dev] atomic intrinsics

[Jeffrey Yasskin]

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?