On Jan 6, 2015, at 11:17 PM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > > On Tue, 6 Jan 2015 16:32:35, Mike Stump wrote: >> >> On Jan 6, 2015, at 3:22 PM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: >>> Yes, I think too that it can't fail under these conditions. >> >> If you mean your version… A lot has been written on how to to make racy code >> non-racy… I’d refer you to the literature on all the various solutions >> people have found to date. I don’t think I’ve ever seen anyone claim that >> affinity can be used to solve race conditions like this. Do you have a >> pointer? >> > > no, I agree, the affinity would just lower the likelihood, as sleep does. > The version with affinity is just disgusting, sorry to have posted it ;-). > > I meant your version, with step(1)/step(2) between the race. It is probably > bullet-proof. > But the version with sleep is more realistic.
> sleep_sync.c can use step but needs still to call sleep because it triggers > on the > "As if synchronized via sleep" diagnostic. Ah, thanks for the pointer. Yeah, it is important to not remove that sleep, though, if the test case itself is racy, we can use step to ensure the elements of it happen in a deterministic order. > I don't know what to make of simple_race.c, which uses usleep, but uses > a loop to repeat the race often. Maybe leave that one as a "realistic" test. I looked at that test case to see if it is flaky (llvm term) and found: http://reviews.llvm.org/D3913 > The tests test that ThreadSanitizer finds the data race in particular > conditions. However, ThreadSanitizer core algorithm can miss a data race when > the racy memory access attempts happen very close to each other (literally > simultaneously). This was done intentionally, fixing this would impose > significant slowdown and this is not a problem for programs other than unit > tests. So, clearly your presentation of the base problem is accurate. I still doubt the costs of a good solution are all that expensive. Anyway, http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140526/219172.html makes it clear that this test case is flakey (and should be fixed). I’d fix it by removing all looping and making it deterministic (with step). We can leave the usleep in there, it doesn’t hurt; though, not sure it adds anything.
