Unprotected reads -> relaxed reads.
Unprotected write -> relaxed write.
The only unprotected write we had was in SkTraceEvent, which it looks like we nabbed from Chrome at some point and changed only to silence TSAN. Chrome's version uses AtomicWord / NoBarrier_Load / NoBarrier_Store, which boils down to the same as here, intptr_t / relaxed load / relaxed store.
This leaves one place where we're lying a bit to TSAN, in include/core/SkLazyPtr.h where we're doing a data-dependent consume load. We're telling TSAN it's consume, but telling any other compiler to compile it as relaxed, given how they all upgrade consume to acquire. This eliminates a barrier for us on ARM. How do you guys deal with this? Just use a consume memory order, take the hit, and hope compilers get smarter one day?
BUG=chromium:465721
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/996763002
No algorithmic changes. The new APIs let us avoid a few ugly trips through void*,
and I've made the consume/acquire/release decision explicitly conditioned on TSAN.
This should fix the attached bug, which is TSAN seeing us implementing the
sk_consume_load() with a relaxed load, where we used to pass __ATOMIC_CONSUME
to TSAN. This restores us to the status quo of a couple weeks ago, where we
use relaxed loads (to avoid an extra dmb on ARM) for all setups except TSAN,
who gets the logically correct memory order, consume.
No public API changes.
TBR=reed@google.com
BUG=chromium:455606
Review URL: https://codereview.chromium.org/908943002
