| commit | 40e5406ca62bb5557a68c4ed87f76827882484b6 | |
| author | Owen Yamauchi <oyamauchi@fb.com> | |
| Wed, 30 Jan 2013 18:58:00 +0000 (30 10:58 -0800) | ||
| committer | Sara Golemon <sgolemon@fb.com> | |
| Mon, 4 Feb 2013 23:49:03 +0000 (4 15:49 -0800) | ||
| tree | 05afc03197fd94019931fbfefa35300f84671dbf | treesnapshot (tar.gz zip) |
| parent | 19275ea368d7dcb48a7400cf5162fb7ba18696a8 | commitdiff |
Delete atomic_add
Instead of rolling our own atomic operations, we should use the C++11 ones. I'm
planning to get the other ones too (inc, dec, cas), but I'm doing them in
separate diffs to keep the diffs manageable-sized, and bisectable in case
something breaks.
The C++11 atomic ops let you specify the memory ordering semantics you want. Our
implementation of atomic_add was equivalent to memory_order_relaxed (i.e. no
memory barriers of any kind), so I stayed with that, for the most part, when
converting. I think this is OK: a lot of the usages are manipulating counters,
and aren't used to synchronize threads. The one exception is
PhpFile::m_refCount, for which I added acquire/release barriers as appropriate.
Also, ARM has a different definition of what's atomically accessible.
Instead of rolling our own atomic operations, we should use the C++11 ones. I'm
planning to get the other ones too (inc, dec, cas), but I'm doing them in
separate diffs to keep the diffs manageable-sized, and bisectable in case
something breaks.
The C++11 atomic ops let you specify the memory ordering semantics you want. Our
implementation of atomic_add was equivalent to memory_order_relaxed (i.e. no
memory barriers of any kind), so I stayed with that, for the most part, when
converting. I think this is OK: a lot of the usages are manipulating counters,
and aren't used to synchronize threads. The one exception is
PhpFile::m_refCount, for which I added acquire/release barriers as appropriate.
Also, ARM has a different definition of what's atomically accessible.
14 files changed: