On 06/15/2010 05:07 PM, Kevin Fitch wrote:
> I have been converting an existing make based build system over to cmake,
> and overall I am loving it so far.
>
> I happened to run across CheckForPthreads.c, and was a little surprised to
> see that it was basically a classic example of racy code.
>
> The two spawned threads both increment res, which is then used as the return
> value of the whole program. So to prove to myself that this was a real
> issue, not just theoretical raciness, I compile the program, and ran it a
> couple million times on my linux box, and 7 of those two million runs
> returned 1 instead of 2. So the chance of screwup is quite small, but
> definitely non-zero.
Hi Kevin,
after having taken a look at CheckForPthreads.c, I would say you are
absolutely right: If C's postfix "++" operator isn't atomic - and AFAIK,
it isn't guaranteed to be - there's a certain probability for one thread
to intercept the other right at "res++" which may result in each thread
storing "1" to "res", so joining both threads isn't sufficient to ensure
a return value of "2". Actually, I can confirm that the program returns
a value of "1" sometimes. In connection with FindThreads.cmake relying
on "2" to indicate a working "pthread" option of the compiler, this is
definitive a bug, IMO - feel encouraged to file an appropriate report.
> Looking over the source I have a few questions:
> Should it protect the increment with a mutex?
The straightest measure to ensure proper functioning.
> Or, should it really just spawn 1 thread? Is there a point to the spawning
> two?
As far as I can see, one thread would be enough to prove the "pthread"
option, but this would also necessitate a change in FindThreads.cmake.
> Is there a purpose to all the prints?
Probably not since FindThreads.cmake doesn't catch them. Maybe, they
serve as a visual verification when the program is launched manually.
> What is the line "if(ac > 1000){return *av[0];}" there for? If it has a
> purpose that definitely deserves a comment.
A subtle joke we don't understand? ;)
> What about the "#if defined(__BEOS__)"... lines? The usleep will only be
> there on BEOS, but the comment on the usleep line mentions sun.
Perhaps, this means BEOS-on-SUN, but I don't know for sure.
Regards,
Michael
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
