Displaying 2 results from an estimated 2 matches for "__tsan_release".
2016 Sep 02
2
call_once and TSan
...t 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_once_callback_wrapper(...) {
orig_func(orig_arg);
__tsan_release(flag);
}
INTERCEPTOR(call_once, o, func, arg) {
REAL(call_once)(flag, ..., call_once_callback_wrapper);
}
Kuba
> On 2 Sep 2016, at 13:42, Dmitry Vyukov <dvyukov at goo...
2016 Sep 02
2
call_once and TSan
...still see a false positive where one thread has already run user code, and another thread already sees that call_once is finished, but the acquire has no release to pair with.
>
>
>
> Will then the following work?
>
> INTERCEPTOR(call_once, o) {
> REAL(call_once)(o);
> __tsan_release_merge(o);
> __tsan_acquire(o);
> }
Still racy. Suppose thread A is still inside REAL(call_once), but already after it has run user code and updated "o" to ~0. Thread B load-acquires "o", finds ~0, assumes it's fully initialized, keeps going, but user code stores ha...