On Wed, Jan 07, 2015 at 08:17:34AM +0100, Bernd Edlinger wrote:
>
> On Tue, 6 Jan 2015 16:32:35, Mike Stump wrote:
> >
> > On Jan 6, 2015, at 3:22 PM, Bernd Edlinger <bernd.edlin...@hotmail.de>
> > wrote:
> >> Yes, I think too that it can't fail under these conditions.
> >
> > If you mean your version… A lot has been written on how to to make racy
> > code non-racy… I’d refer you to the literature on all the various solutions
> > people have found to date. I don’t think I’ve ever seen anyone claim that
> > affinity can be used to solve race conditions like this. Do you have a
> > pointer?
> >
>
> no, I agree, the affinity would just lower the likelihood, as sleep does.
> The version with affinity is just disgusting, sorry to have posted it ;-).
>
> I meant your version, with step(1)/step(2) between the race. It is probably
> bullet-proof.
> But the version with sleep is more realistic. That is however just a matter
> of taste...
>
> If we can agree to use your version, then all tests in g++.dg/tsan and
> c-c++-common/tsan that currently use sleep(1) should use your step function
> instead.
> sleep_sync.c can use step but needs still to call sleep because it triggers
> on the
> "As if synchronized via sleep" diagnostic.
>
> I don't know what to make of simple_race.c, which uses usleep, but uses
> a loop to repeat the race often. Maybe leave that one as a "realistic" test.
I'm fine with adding the no_sanitize_thread attribute, the patch LGTM, I
think we might even have a PR for that.
But I really don't like the busy waiting. You essentially want something
like pthread_barrier_wait that libtsan isn't aware of, right?
As tsan is only supported on x86_64-linux (and in the future could be on
some other 64-bit linuxes), I wonder if we couldn't just simplify libgomp's
config/linux/bar* for that purpose - libtsan doesn't intercept syscall(3)
and doesn't intercept futex in particular, so we could have a busy waiting
free synchronization primitive. Or another option is to just dlopen
libpthread.so.0 and dlsym pthread_barrier_wait in it and use that, that way
libtsan won't intercept it either.
Jakub
