On Tue, Jan 06, 2015 at 10:08:22AM +0100, Bernd Edlinger wrote:
> Hi Mike,
>
> after some hours of sleep I realized that your step function can do something
> very interesting,
> (which you already requested previously):
>
> That is: create a race condition that is _always_ at 100% missed by tsan:
>
> cat lib.c
> /* { dg-do compile } */
> /* { dg-options "-O2 -fno-sanitize=all" } */
>
> static volatile int serial = 0;
>
> void step (int i)
> {
> while (__atomic_load_n (&serial, __ATOMIC_ACQUIRE) != i - 1);
> __atomic_store_n (&serial, i, __ATOMIC_RELEASE);
> }
Such busy waiting is not very CPU time friendly in the testsuite, especially
if you have just a single HW thread.
If libtsan is not fixed not to be so racy, perhaps instead of all the sleeps
we could arrange (on x86_64-linux, which is the only target supporting tsan
right now) to make sure the thread runs on the same core/hw thread as the
initial thread using pthread_[gs]etaffinity_np/pthread_attr_setaffinity_np ?
Does tsan then always report the races when the threads can't run
concurrently?
Jakub
