This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++11 atomic library notes
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Lawrence Crowl <crowl at google dot com>, Benjamin Kosnik <bkoz at redhat dot com>, Richard Henderson <rth at redhat dot com>, Aldy Hernandez <aldyh at redhat dot com>, GCC <gcc at gcc dot gnu dot org>
- Date: Sat, 1 Oct 2011 08:55:59 +0200 (CEST)
- Subject: Re: C++11 atomic library notes
- References: <4E862864.2010607@redhat.com>
- Reply-to: gcc at gcc dot gnu dot org
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