Instead of std::atomic APIs for atomic operations, we instead use APIs
include with sanitizer_common. This allows us to, at runtime, not have
to depend on potentially dynamically provided implementations of these
atomic operations.
Currently only do this for x86_64.
Fixes http://llvm.org/PR32274.
This lock is being held over all Buffers (which may not be that bad actually). It is also held during the only use of apply(), which calls retryingWriteAll() and therefore will take a lot of time, including passively waiting on system calls. It would therefore make sense to use the blocking mutex here, to avoid burning CPU for potentially milliseconds.
Is there any downside to a blocking lock in this scenario? The other ones look fine as the locks only protect very small regions of memory.