On Jan 7, 2015, at 2:44 PM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > Here is a new patch, that uses this method on all tsan tests, > which seem to depend on sleep(1), and which have unstable results > because of that.
> OK for trunk? No. So, I think this is wrong. The problem is that any synchronizing primitive can trapped by tsan and added to the analysis, and if it resolves the race, then it should change the analysis that tsan produces. The point of the atomic set, load primitives and volatile, the code-gen is a single instruction that tsan by definition, won’t now, or ever instrument because we tell it explicitly, don’t with no_sanitize_thread. Since gcc now supports no_sanitize_thread, I don’t know of any reason why the test cases should not now be fixed to use step.
