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
