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
