On Thu, Jan 08, 2015 at 11:24:21AM -0800, Mike Stump wrote: > 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.
I disagree. Busy waiting of this kind is not appropriate for the testsuite, we burn already way too much time and adding to that is undesirable. tsan can't intercept the calls that you do through dlsym, because you explicitly bypass tsan in that case. > 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. See above. Jakub