Clean up SkDynamicAnnotations.

    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

1 files changed, 2 insertions, 3 deletions

diff --git a/src/core/SkLazyFnPtr.h b/src/core/SkLazyFnPtr.h
index 464e061a13..9e9bc1165c 100644
--- a/src/core/SkLazyFnPtr.h
+++ b/src/core/SkLazyFnPtr.h
@@ -31,8 +31,7 @@
 
 // Everything below here is private implementation details.  Don't touch, don't even look.
 
-#include "SkDynamicAnnotations.h"
-#include "SkThreadPriv.h"
+#include "SkAtomics.h"
 
 namespace Private {
 
@@ -42,7 +41,7 @@ class SkLazyFnPtr {
 public:
     F get() {
         // First, try reading to see if it's already set.
-        F fn = (F)SK_ANNOTATE_UNPROTECTED_READ(fPtr);
+        F fn = (F)sk_atomic_load(&fPtr, sk_memory_order_relaxed);
         if (fn != NULL) {
             return fn;
         }