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. That is however just a matter of
taste...
If we can agree to use your version, then all tests in g++.dg/tsan and
c-c++-common/tsan that currently use sleep(1) should use your step function
instead.
sleep_sync.c can use step but needs still to call sleep because it triggers on
the
"As if synchronized via sleep" diagnostic.
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.
Bernd.
