Re: C++11 atomic library notes

[Marc Glisse <marc.glisse@inria.fr>]

On Fri, 30 Sep 2011, Andrew MacLeod wrote:

> I've been working on GCC's C++11 atomic implementation.

Cool!

> In discussions with 
> Lawrence, I've recently discovered a fundamental change in what libstdc++-v3 
> is likely to provide as far as an implementation.
>
> Previously, header files provided a choice between a locked or a lock-free 
> implementation, preferring the lock-free version when available on the 
> architecture and falling back to the locked version in other cases.
>
> Now the thought is to provide lock-free instructions when possible, and fall 
> back to external function calls the rest of the time. These would then be 
> resolved by an application or system library.
>
> If proceeding with that change, it would be convenient to make the same calls 
> that other implementations are going to use, allowing OS or application 
> providers to simply provide a single library with atomic routines that can be 
> used  by multiple C++11 compilers.
>
> Since GCC 4.7 stage 1 is going to end shortly and it would be nice to get the 
> cxx-mem-model branch integrated, I quickly wrote up what the current plan for 
> the branch is regarding these external calls and such and brought up a couple 
> of issues.  Its located in the gcc wiki at: 
> http://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary

"The compiler must ensure that for any given object, it either ALWAYS 
inlines lock free routines, OR calls the external routines. For any given 
object, these cannot be intermixed."

Why? You give an example explaining why it is fine to link 386 and 486 
objects, and I cant see the difference. Not that I'm advocating mixing 
them, just wondering whether it really matters if it happens (by 
accident).

I assume that locks are supposed to be implemented in terms of those 
functions too (it sounds like lock uses atomic which uses lock ;-)

For the atomic version of a user-defined "small" POD type, do you intend 
to query the compiler about the presence of a volatile member to dispatch 
to the right function?

The design looks a lot like:
http://libcxx.llvm.org/atomic_design_a.html
which is good since the main point seems to be to share it between 
implementations. Are there others on board?

-- 
Marc Glisse