Skip to content

Improvements to Threading Configuration

Simon Spannagel requested to merge plotting into master

This started out as a solution to #208 (closed) but somehow diverted a bit. I would suggest to close #208 (closed) since the cases in which MT is now disabled are not meant to be run on large-batch events in MT mode anyway. But this got me realizing that the current way the logging is done for multihtreading is a bit odd:

  • While constructing modules (Allpix::load()) they report on their multithreading capabilities, based on their configuration - no info on this here
  • In Allpix::initialize() we set out to figure out the number of threads to be used - no info here
  • Finally, in Allpix::run() we get the buffer depth and then notify the user that MT is off - a bit late IMHO.
  • There never is any info on why MT has been switched off, unless the module itself issues a message

New flow works as follows:

  • While constructing modules (Allpix::load()) they report on their multithreading capabilities, we immediately log which modules cannot to MT if it was initially requested
  • In Allpix::initialize() we get all threading configuration together and inform the user about the final decision (MT on/off). We also book performance plots here.
  • In Allpix::run() we only click on "Run!" and get the simulation going

Also, I removed the stats_mutex from GenericPropagation (that was where I started) since it's not necessary - the vector it tries to protect is local to the run() method - and in addition will only be filled in ST mode anyway.

Merge request reports