Skip to content

Standalone Fixes, master branch (2019.10.09.)

I was doing some tests with compiling Gaudi against the very latest TBB version in a "standalone way", and I had to make a couple of updates to make this happen.

First off there were a couple of errors in the CMake configuration of the project that crept in since the last time that I tried such a standalone compilation. I had to make some tweaks in how cppgsl and Range-v3 would be downloaded/used by the code when not picking these up from the system/LCG release.

The more controversial part is what I had to do in the C++ code... In the very latest version of TBB Intel retired some old classes. (They are still available if one uses __TBB_LEGACY_MODE=1 for the build, but I didn't want to do that...)

As far as I can see tbb::recursive_mutex was removed without a replacement. I guess because std::recursive_mutex is in a "good enough" state by now that we should rather be using that. Still, since I didn't want to change the behaviour of Gaudi with the current TBB version(s), instead of simply switching to std::recursive_mutex all across the board, I only did it conditionally. Though we may want to just switch to the std type all together at this point, it would result in cleaner code.

The even more tricky part is that Intel removed tbb::task_scheduler_init from TBB's public interface. As far as I understand one is only supposed to use tbb::global_control by now. But since in my experience tbb::global_control is not behaving all that great in older TBB versions, I think we definitely need to keep using some conditional statements in that part of the code...

I'm open to suggestions on all of these things of course, but I do think that we need to go in this general direction with TBB's usage. CC-ing @leggett, @clemenci, @bwynne and @ishapova as the primary interested parties on this (I guess...).

Merge request reports

Loading