Chrome's tracing framework appears to be intentionally racy on its
quick-reject checks, trading some data loss for better performance
when disabled. People will never notice the data loss, but TSAN does.
Let's assuage TSAN with some annotations.
The 'volatile' val in SK_ANNOTATE_UNPROTECTED_WRITE was making this
not compile, but that volatile doesn't really make sense there: the value we're
writing is not what we care about, it's the destination.
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-TSAN-Trybot
No API changes.
TBR=reed
BUG=skia:
Review URL: https://codereview.chromium.org/702883002
SkRacy<T> is a zero-overhead wrapper for a T, except it also
silences race warnings when TSAN is running.
Here we apply in several classes. In SkMatrix and SkPathRef,
we use it to opportunistically cache some idempotent work.
In SkPixelRef, we wrap the genIDs. We think the worst that
can happen here is we'll increment the global next-genID a
few times instead of once when we go to get another ID.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/d5e3e6ae1b3434ad1158f441902ff65f1eeaa3a7
CQ_EXTRA_TRYBOTS=tryserver.skia:Canary-Chrome-Ubuntu13.10-Ninja-x86_64-ToT-Trybot,Canary-Chrome-Win7-Ninja-x86-SharedLib_ToT-Trybot,Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-TSAN-Trybot
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/371363004
Reason for revert:
hidden symbol 'AnnotateBenignRaceSized' in obj/base/third_party/dynamic_annotations/libdynamic_annotations.a(obj/base/third_party/dynamic_annotations/dynamic_annotations.dynamic_annotations.o) is referenced by DSO lib/libblink_platform.so
Original issue's description:
> Add SkRacy
>
> SkRacy<T> is a zero-overhead wrapper for a T, except it also
> silences race warnings when TSAN is running.
>
> Here we apply in several classes. In SkMatrix and SkPathRef,
> we use it to opportunistically cache some idempotent work.
>
> In SkPixelRef, we wrap the genIDs. We think the worst that
> can happen here is we'll increment the global next-genID a
> few times instead of once when we go to get another ID.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/d5e3e6ae1b3434ad1158f441902ff65f1eeaa3a7R=reed@google.com, mtklein@chromium.orgTBR=mtklein@chromium.org, reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/377693005
SkRacy<T> is a zero-overhead wrapper for a T, except it also
silences race warnings when TSAN is running.
Here we apply in several classes. In SkMatrix and SkPathRef,
we use it to opportunistically cache some idempotent work.
In SkPixelRef, we wrap the genIDs. We think the worst that
can happen here is we'll increment the global next-genID a
few times instead of once when we go to get another ID.
BUG=skia:
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/371363004
