Multi-threading data races

[kimwalisch]

There are a few non-critical data races in primecount where multiple threads write/read to some variable without using a mutex or lock. I am not aware of any CPUs where this could cause a segmentation fault but it is still best to fix these data races.

$ valgrind --tool=drd ./primecount --test

==23554== Conflicting store by thread 1 at 0x0036c411 size 1
==23554==    at 0x128080: primecount::set_print(bool) (in /home/kim/Desktop/primecount-master/build3/primecount)
==23554==    by 0x11AEDA: primecount::pi_legendre(long, int) (in /home/kim/Desktop/primecount-master/build3/primecount)

==23554== Conflicting store by thread 1 at 0x0036c418 size 4
==23554==    at 0x14DE88: primesieve::set_num_threads(int) (in /home/kim/Desktop/primecount-master/build3/primecount)
==23554==    by 0x11B950: primecount::pi_primesieve(long, int) (in /home/kim/Desktop/primecount-master/build3/primecount)

Multiple threads are allowed to read the same variable without locking. But multiple threads are not allowed to write/read the same variable without locking. Both primecount::set_print(bool) and primesieve::set_num_threads(int) are write accesses without locking which is not allowed and which causes a data race.

[kimwalisch]

I don't want to use locking inside primecount so the easiest fix would be to simply remove the calls to primecount::set_print(bool) and primesieve::set_num_threads(int).

The call to primesieve::set_num_threads(int) could indeed simply be removed without deteriorating primecount but removing primecount::set_print(bool) requires some work because this would deteriorate the --status option.

[kimwalisch]

Fixed.