Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C

[Mike Stump <mikestump@comcast.net>]

On Jan 6, 2015, at 3:22 PM, Bernd Edlinger <bernd.edlinger@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?

> If we prepare the test in this way it does not really contain any race condition.
> 
> (*p4).val++;
>   step (1);
> 
> happens first, and then:
> 
>   step (2);
>   Global[1]++;
> 
> but we consider the test passed, when we see a diagnostic?

If tsan doesn’t work in the face of a race, then trivially, the code to test it cannot have a race.  The difference is letting tsan know there is a race, versus hiding the fact there is no race from it, so that it still thinks there is a race.  For test cases to diagnose a race, those cases must have the code that ensures there is not a race, hidden from view.

> As far as I can see, there is no interceptor for sched_yield, so using that in the step function is OK.

Sounds good.

I’m running a test suite run now with my attribute patch.  I’ll ask the tsan people if it can go in, if it passes.