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.htmland: 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