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? > 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.
