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:
int order = 0;
void sync(int i) {
while (++order != i) { /* atomic inc */
--order; /* atomic dec */
sleep(1); /* or some type of operative yield */
}
}
thread 1:
asm (“call sync(1)”);
action1;
asm (“call sync(3)”);
action3;
thread 2:
asm (“call sync(2)”);
action2;
where the order executed would be action1, action2, action3. The asm hides all
details of the synchronization from everyone, optimizer, tsan.
Now, why go to all this work? Simply, determinism in gcc and the test suite,
is, well, nice. I understand that user programs won’t be so nice, and that in
the wild, it won’t be 100%.
