[PATCH] D14745: [tsan] Implement basic GCD interceptors for OS X

[Kuba Brecka via llvm-commits]

kubabrecka added a comment.

In http://reviews.llvm.org/D14745#290906, @dvyukov wrote:

> Doh! Don't know whether I need to laugh or cry.
>  If you mean this one:
>  http://www.opensource.apple.com/source/libdispatch/libdispatch-339.1.9/dispatch/once.h
>  It does contain real, harmful data race. Load of predicate on fast path must be an atomic load with acquire memory ordering.
>
> First we need to fix the actual bug in libdispatch.
>  Then you can do the same thing I did for pthread_once. Namely, reimplement dispatch_once entirely expecting that the inlined fast-path will load acquire load of the predicate address.


I talked to the maintainers of libdispatch, and I couldn't convince them that the race is actually harmful (including linking to https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong).  I think they'd be fine with changing the read into a *relaxed* atomic read (because that wouldn't actually change the generated ASM instructions), but that's still not enough for us (it needs to be *acquire*).  Even if they did change it into a *load acquire* that TSan would catch, there'll be these issues left:

1. TSan will miss the *load acquire* in already compiled code (system libraries).  This is unfortunately quite common.
2. It will only work properly in the next OS X release.

So at this point, I'd like to implement something that 1) works on current OS X and 2) doesn't produce false positives in system libraries.  If you know of a better way (other than disabling reads/writes in the initializer), I'll be glad to consider it.


http://reviews.llvm.org/D14745