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.
