[PATCH] [Tsan] Fix the signal_recursive.cc test to pass on systems with high loads
Viktor Kutuzov
vkutuzov at accesssoftek.com
Tue Dec 9 04:44:31 PST 2014
================
Comment at: test/tsan/process_sleep.h:4
@@ +3,3 @@
+static void process_sleep(int sec) {
+ clock_t beg = clock();
+ while((clock() - beg) / CLOCKS_PER_SEC < sec)
----------------
dvyukov wrote:
> Humm... clock() returns CPU time used by the process.
> It looks somewhat dangerous to use in most of the tests. If the process is blocked it does not consume CPU time. Of course, this very loop consumes a dash of CPU time every millisecond... But it's not what we want to wait for.
> sleep(1) worked well for us all other tests. I would rather it here as well.
The problem with sleep() is that on systems operating under somewhat stress conditions there is no guarantee the threads are synchronized as we expect it, so even with sleep(4) we still get failures on the buildbot with this test from time to time. Moreover, this test is not the only one that fail only somtimes due to use of sleep(). (However, I'm not sure we are absolutely free of this kind of failures when using the clock() func; we could give it a try and see.) Anyway, if, for whatever reason, this approach is not acceptable, then we probably should state it explicitly that Tsan tests require a dedicated buildbot by their design and nature.
http://reviews.llvm.org/D6504
More information about the llvm-commits
mailing list