On Monday, November 22, 2010 12:34:04 pm Richard Sandiford wrote: > For the record, the thing I half-remembered on the call was: > > http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00697.html > and: > http://gcc.gnu.org/ml/gcc-patches/2009-09/msg02112.html > > The problem is that all __sync operations besides __sync_lock_test_and_set > and __sync_lock_release are defined to be full barriers. Using something > like __sync_val_compare_and_swap for __arch_compare_and_exchange_val_*_acq > and __arch_compare_and_exchange_val_*_rel may on some architectures be too > heavyweight, since those macros only need acquire/after and release/before > barriers. See in particular: > > http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00928.html
Hi Richard, Thanks for providing these pointers. I wasn't aware of them. > from the first thread, where the feeling was that the future wasn't > these __sync builtins, but the new C and C++ atomic memory support. This was also suggested by Joseph S. Myers on the libc-ports list: http://sourceware.org/ml/libc-ports/2010-11/msg00013.html Regards Ken _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
