On Sun, Jan 04, 2015 at 11:04:34AM -0800, Mike Stump wrote:
> On Jan 3, 2015, at 3:20 AM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote:
> > Yes, but all other tsan test cases call sleep(1) too.
>
> Ick. The problem is pushing bugs to obscure them without fixing them, makes
> the system inherently less good.
>
> If there is already one bug that documents the problem that the sleep cures
> then it is fine to so obscure the bug. At least 1 test case should remain
> that isn’t obscured. Indeed, if you can enhance the failure rate of the test
> case that shows the failure, ideally to 1/1, that would be great. There is
> no need to have more than one test case that doesn’t have the sleep, but, all
> the test cases with the sleep should have a comment on sleep that points to
> the PR that documents the problem.
>
> [ reviewing all the c++ tsan cases ]
>
> Ah, even more curious. So, for testing, it would be best if we had a way to
> synchronize the threads so that they reliably can show what you want to show,
> and reliably pick which thread will run first and which second and so on.
> The problem is of course, the synchronization primitives can’t get in the way
> (be seen by) of normal tsan functioning. I’m thinking asm() can so obscure
> arbitrary things, but I’m not sure I can’t think of a way to do that with
> anything less. sleep is close, and, at least portable and simple. What it
> isn’t is bullet proof. The tsan test cases would be enhanced if we could
> find a way to synchronize the threads invisibly to tsan. I’d like to think
> that someone can propose a better scheme than sleep. My thought would be
> something like:
Yeah, I think it was just a bad idea to add testsuite for something that is
racy. So, either we should disable tsan testsuite by default, or change
libsanitize/tsan/, so that it can be built as a perhaps slower, but not racy
variant, and test only that variant.
Jakub
