Feature #521

MAUSRun, MAUSProcess

Added by Rogers, Chris almost 13 years ago. Updated almost 12 years ago.

Online reconstruction
Target version:
Start date:
23 June 2011
Due date:
% Done:


Estimated time:


Email to maus-devs on 09/06/2011

So there are a few places where we need or want global objects. Examples

Iniitialise once per run per process:
Field maps
Virtual planes

Initialise once per process:
Geant4 (would like to be once per run, but not allowed)
Configuration cards

May be some stuff in recon?

At the moment they are implemented as singletons or just as some random
thing. So singleton is a C++ way of doing a global variable. Have a look

The problem with all this singleton stuff is that memory allocation and
deallocation is a pain. Two problems:

  • Memory deallocation order needs to be handled carefully (what if I
    want to use Logging while deallocating Geant4? Which one was deleted first?)
  • Memory allocation can get screwed up in multithreading - two threads
    can attempt to allocate memory at the same time - leading to problems:

We live with this right now, but we will suffer if we try to
multithread, and we will leak memory per run per process.

My plan is to introduce two "configuration managers" - one that exists
for the duration of a run (say MAUSRun), one that exists for the
duration of a process (say MAUSProcess).

MAUSProcess has accessors to the per process objects and the MAUSRun
MAUSRun has accessors to the per run objects

If we multiprocess, we make multiple copies of this stuff.

Plan? Comments?

Related issues

Related to MAUS - Feature #373: Configuration managementRejectedRogers, Chris10 March 2011


Updated by Rogers, Chris almost 13 years ago

  • Category changed from common_cpp to Online reconstruction

Updated by Rogers, Chris over 12 years ago

  • Assignee changed from Rogers, Chris to Jackson, Mike

Mike, I think this is now your responsibility? I can help/do it if you aren't sure.


Updated by Rogers, Chris over 12 years ago

Email from Chris Tunnell:

This is a ways away and things like geant4 parallelization aren't required in the control room. It's fine that we're bookeeping what the jobs are and how we hope they'll be done one day, but I thought we said the parallelization stuff happens after we address dataflow? Just want to make sure we don't create distractions...?

(posted by email, can post by issue tracker if you want).


Updated by Rogers, Chris over 12 years ago

I agree, the only thing is we need even single threaded to rebuild the geometry and fields (the currents change, proton absorber/diffuser moves).


Updated by Rogers, Chris about 12 years ago

  • Assignee changed from Jackson, Mike to Rogers, Chris

Updated by Rogers, Chris almost 12 years ago

  • Status changed from Open to Rejected

Also available in: Atom PDF