(potential?) data-races

[KrisThielemans]

Running Intel Inspector (with the Intel compiler) gives me a few data-races. Of course, I'm not sure if these are false positives or not

when checking internal ProjDataInfo data-structures were initialised

STIR/src/include/stir/ProjDataInfoGenericNoArcCorr.inl

Lines 43 to 44 in 9e40811

	#pragma omp atomic read
	initialised = uncompressed_view_tangpos_to_det1det2_initialised;

conflicts with

STIR/src/buildblock/ProjDataInfoCylindricalNoArcCorr.cxx

Line 228 in 9e40811

uncompressed_view_tangpos_to_det1det2_initialised = true;

(and equivalent for Generic).

This implementation of the Double-Checked-Locking(DCL) pattern was suggested at http://stackoverflow.com/questions/27975737/how-to-handle-cached-data-structures-with-multi-threading-e-g-openmp.
I see that I didn't use the atomic write in the .cxx [Edit: this is now fixed by #1256], but adding that doesn't seem to make Intel Inspector happy.

I can make these disappear by initialising these tables in the constructor, i.e. commenting out lines like

STIR/src/buildblock/ProjDataInfoCylindricalNoArcCorr.cxx

Lines 73 to 74 in 9e40811

	//this->initialise_uncompressed_view_tangpos_to_det1det2();
	//this->initialise_det1det2_to_uncompressed_view_tangpos();

However, that causes a slow-down as these tables take a while to construct. For example,

time ./run_test_simulate_and_recon.sh

before

real    0m23.021s
user    4m12.391s
sys     0m2.925s

after

real    0m33.966s
user    4m39.860s
sys     0m10.009s

detector position access in `DetectorCoordinateMap::get_coordinate_for_det_pos`

STIR/src/include/stir/DetectorCoordinateMap.h

Lines 91 to 93 in 9e40811

	coord.x() += static_cast<float>(distribution(generator));
	coord.y() += static_cast<float>(distribution(generator));
	coord.z() += static_cast<float>(distribution(generator));

conflicts with some internal randoms stuff.

This will be because std random generators are not thread-safe.
I think we need one generator per thread (probably a vector of size get_max_num_threads(). @markus-jehl feel like looking at that one?

[markus-jehl]

sure, I'll put the second one on my list

[markus-jehl]

@KrisThielemans : can this be closed?

[KrisThielemans]

I haven't re-run Intel inspector, but as we are not experiencing any problems, I agree we concluse this now.