[cfe-dev] atomic intrinsics

[Howard Hinnant]

Thanks Jeffrey, comments below:

On Oct 7, 2010, at 4:58 AM, Jeffrey Yasskin wrote:

> On Wed, Oct 6, 2010 at 9:19 AM, Howard Hinnant <hhinnant at apple.com> wrote:
>> In the hopes of clarification, I've put three design descriptions up at:
>> 
>> http://libcxx.llvm.org/atomic_design.html
>> 
>> A and/or B is what Eric proposed.  C is what I've been working toward.  A is my preference.  But I can't implement A without buy-in from the front end team.  Heck, I can't actually implement any of them without said buy-in. :-)  I chose C originally because that was where I thought I could most likely get buy-in.
>> 
>> If any of those docs are unclear, just let me know and I'll attempt to clarify what is intended.
> 
> * volatile: The optimizers can do a better job with non-volatile
> atomic operations. I believe in your initial atomic_flag
> implementation you forwarded the argument's volatility to the
> intrinsic, and if the compiler implements the intrinsics it can detect
> whether the argument is volatile and optimize accordingly, so that's
> all good. But in these API proposals you only have the volatile
> intrinsics listed, which might mislead compiler authors to think that
> every atomic op has to be volatile. I think it'd be worth mentioning
> that notionally there are volatile and non-volatile versions of each
> intrinsic.

Updated only Design A:

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

> 
> * "POD" isn't quite the right restriction. [atomics.types.generic]p1
> says "The type of the template argument T shall be trivially
> copyable." There may be an NB comment suggesting an extra restriction,
> but I don't remember exactly what it said.

Updated Design A:

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


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

-Howard