Hi, On Wed, 21 Jan 2015 12:58:27, Dmitry Vyukov wrote: > > > The step approach looks better to me at first sight. > > Busy waiting looks like a weak argument in this context. It's > absolutely non performance-critical and a yield or usleep(10) will > solve it more than sufficiently. > > I will check how complex to make its implementation invisible to tsan > (I suspect that clang does not ignore atomic operations when > no_sanitize_thread attribute is given) and whether it actually makes > more complex tests simpler to write (as compared to the barrier > approach).
Yes, for Gcc this is a pretty new feature, so I dont think we should use it now. It _should_ suppress the instrumentation of atomics, but it can not be used to avoid intercepted calls like usleep, and using sched_yield is safe, but usleep is intercepted, and may change the printed diagnostics. But unfortunately it is not really stable at the time: cat test.c volatile int serial=0; __attribute__((no_sanitize_thread)) void step (int i) { while (__atomic_load_n (&serial, __ATOMIC_ACQUIRE) != i - 1) sched_yield(); __atomic_store_n (&serial, i, __ATOMIC_RELEASE); } gcc -S -fsanitize=thread test.c test.c: In function 'step': test.c:6:6: warning: implicit declaration of function 'sched_yield' [-Wimplicit-function-declaration] sched_yield(); ^ test.c:3:6: internal compiler error: in expand_TSAN_FUNC_EXIT, at internal-fn.c:243 void step (int i) ^ 0x966b17 expand_TSAN_FUNC_EXIT ../../gcc-5-20150118/gcc/internal-fn.c:243 0x75438f expand_call_stmt ../../gcc-5-20150118/gcc/cfgexpand.c:2311 0x75438f expand_gimple_stmt_1 ../../gcc-5-20150118/gcc/cfgexpand.c:3327 0x75438f expand_gimple_stmt ../../gcc-5-20150118/gcc/cfgexpand.c:3481 0x75a862 expand_gimple_basic_block ../../gcc-5-20150118/gcc/cfgexpand.c:5394 0x75c087 execute ../../gcc-5-20150118/gcc/cfgexpand.c:6003 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. Bernd.