search for: __tsan_acquire

...part of >>> runtime and build them with exceptions. >>> >>> Alternatively, the interceptor can handle only synchronization but >>> forward actual logic to the real function. Along the lines of: >>> >>> INTERCEPTOR(call_once, o) { >>> __tsan_acquire_release(o); >>> REAL(call_once)(o); >>> } >>> >>> That will have some performance impact. If we hardcode the "fully >>> initialized" value, then we can eliminate the additional overhead: >>> >>> INTERCEPTOR(call_once, o) { &...

...// <=== user code callback mutex_lock(mut); atomic_store(&flag, FULLY_INITIALIZED, mo_release); // "release" store, but within a compiled dylib, thus invisible to TSan } mutex_unlock(mut); } If thread A is just after the release store, which is invisible to TSan, __tsan_acquire in thread B will have no effect, and the stores from the callback to func(arg) will not be synchronized to thread B. Anyway, I just realized that we can wrap "func" into our own callback, which will perform the (extra) __tsan_release... Do you think that would work? E.g.: void call_on...

...interceptors). We could add additional files to the cxx part of > runtime and build them with exceptions. > > Alternatively, the interceptor can handle only synchronization but > forward actual logic to the real function. Along the lines of: > > INTERCEPTOR(call_once, o) { > __tsan_acquire_release(o); > REAL(call_once)(o); > } > > That will have some performance impact. If we hardcode the "fully > initialized" value, then we can eliminate the additional overhead: > > INTERCEPTOR(call_once, o) { > if (__atomic_load(o, acquire) == FULLY_INITIALIZED...

Hi, I'm trying to write a TSan interceptor for the C++11 call_once function. There are currently false positive reports, because the inner __call_once function is located in the (non-instrumented) libcxx library, and on macOS we can't expect the users to build their own instrumented libcxx. TSan already supports pthread_once and dispatch_once by having interceptors that re-implement the