search for: __tsan_acquire_release

Displaying 4 results from an estimated 4 matches for "__tsan_acquire_release".

2016 Sep 02
2
call_once and TSan
...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) { >...
2016 Sep 02
2
call_once and TSan
...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) { >>&...
2016 Sep 01
2
call_once and TSan
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
2016 Sep 02
2
call_once and TSan
...h 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: >>>>> &g...