Firstly thanks a lot for working on this.
On 28/11/2018 12:49, Jonathan Wakely wrote: > On 28/11/18 12:30 +0000, Jonathan Wakely wrote: >> 3) We could change libstdc++'s configure to automatically override >> --with-libstdcxx-lock-policy for arm-linux so it always uses "atomic" >> (because we know the kernel helpers are available). That causes an ABI >> change for a GCC built for --target=armv5t-*-linux* so I didn't do >> that by default. Packagers who want that can use the --with option >> explicitly to build a libstdc++ with atomic refcounting that can be >> used on any armv5t or later CPU, allowing users to choose a newer >> -march for their own code. (Until my patch that didn't work, because > > [...] > >> Option 3) is not my call to make. If the ARM maintainers want to >> change the default older arm-linux targets I have no objections. We could change the defaults when(if) we next bump up the libstdc++ ABI in general :-/ and if we remember to do this. I don't feel comfortable changing the defaults silently and I don't view this as something we can decide on by ourselves as the Arm maintainers as this really falls in the space of folks distributing Linux using by defaults versions of the architecture that result in the use of mutexes rather than the atomics. It's also not clear to me if we can use any other magic tricks to make this co-exist and whether that is worth it. > > Another way to approach option 3) that we discussed at Cauldron, and > which I want to start a separate discussion about on g...@gcc.gnu.org, > is to change the value of __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 et al > when we have kernel helpers to implement those operations. > > The shared_ptr code doesn't care if an atomic CAS comes from the CPU > or a kernel helper in libgcc. If the atomic CAS is supported via > kernel helpers, let's use it! But those predefined macros only tell > you about native CPU support (for the current target selected by > -march). > > > It's worth noting that all this shared_ptr code predates libatomic, so > we couldn't just say "always use atomics, and link to libatomic if > needed". If __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 was not defined, we had > to assume no CAS *at all*. Not native, not provided by libatomic, > nothing. I'd love to simply rely on std::atomic in std::shared_ptr, > but that would be an ABI break for targets currently using a mutex, > and would add new dependencies on libatomic for some targets. (It > might also pessimize some single-threaded programs on targets that do > use atomic ref-counts, because currently some updates are non-atomic > when __gthread_active_p() == false). Yep, though you want it to go to the kernel helpers or indeed libatomic. regards Ramana > >
