search for: fully_initialized

..._once does: __call_once(flag, arg, func) { mutex_lock(mut); if (flag == BEING_INITIALIZED) { wait } else if (flag == NOT_INITIALIZED_AT_ALL) { flag = BEING_INITIALIZED; mutex_unlock(mut); func(arg); // <=== 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 n...

...>>> } >>> >>> 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) { >>> __tsan_acquire(o); >>> return; >>> } >>> __tsan_acquire_release(o); >>> REAL(call_once)(o); >>> } >> >> Unfortunately, the first fast-path check is inlined and cannot be intercepted. We can only intercept the inner cal...

...; __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) { > __tsan_acquire(o); > return; > } > __tsan_acquire_release(o); > REAL(call_once)(o); > } Unfortunately, the first fast-path check is inlined and cannot be intercepted. We can only intercept the inner call to __call_once. But how would __tsan_acquire_release help...

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