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

[Andrew MacLeod]

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.

If the target is multithreaded, well, we'll have to go to a lock I 
guess...   Are there any multithreaded targets without atomic support?  
ie, is this one?

Andrew