Re: cxx-mem-model merge [6 of 9] - libstdc++-v3

[Torvald Riegel <triegel@redhat.com>]

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