This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: cxx-mem-model merge [6 of 9] - libstdc++-v3
On Fri, 2011-11-11 at 12:45 -0500, Andrew MacLeod wrote:
> On 11/11/2011 12:43 AM, Benjamin Kosnik wrote:
> >
> >> bkoz: As relates to the existing problem, how is the legacy support
> >> invoked in compatibility-atomic-c++0x.cc? That has the old style
> >> implementation of atomic_flag with a lock, which would allow this
> >> target to compile... which is another option perhaps. or is that
> >> purely for pervious releases somehow?
> > compatibility-atomic-c++0x.cc is the support for previous builtins
> > attempt, let's call this atomics-try-2. We need to keep these symbols
> > exported and doing the same thing done in previous releases. (Or else
> > abi-check will fail.)
> >
> > If this system used to use a lock to work, then that is what it should
> > still do. The behavior shouldn't change.
> >
> I think there is also an argument for single threaded-ness vs multi
> threaded. If there is no atomic support and its single threaded, we
> don't really need the lock... and I'm not sure how you can detect the
> change in behaviour if test_and_set and clear just store 1 and 0 rather
> than create alock, then do the store of 1 or 0.
Also, if you're replacing it with atomic ops you can't see different
behavior because, well, they are atomic. However, this requires that
_nobody_ tries to synchronize using this lock anymore (only observing
the lock is fine, but you must never modify it). Likewise on a
single-threaded target.
Torvald