My application has the ability to read in event configurations from a text file, and process the resulting events. I’ve set up the reader with appropriate mutexes, so that each thread gets one complete event, and successive events get read in by the various worker threads.
When the file reaches EOF, I have the code call G4RunManager::AbortRun(). This should end the run even if the user’s
/run/beamOn had requested more events than the file contains.
But that doesn’t seem to be happening. In a 20 thread job, I had a 200 event file get recycled five times, giving me a final output of 988 “events.” Should I be able to use
AbortRun() the way I have described? Is there something extra I need to do with the RunManager to make it work?
My understanding is that in a multithreaded application the G4RunManager will return a pointer to the thread-local instance of an object, when a thread-local instance of the object exists. I assume that AbortRun() is being called on the thread-local G4Run but the G4Runs on other threads don’t have knowledge of that.
I haven’t tested this whatsoever, so I can’t claim that it will work, but I notice that G4MTRunManager has a static function G4MTRunManager::GetMasterRunManager(). I assume if you retrieved a pointer to the master run manager and called AbortRun() on that, you might get the behaviour you’re looking for.
I hope this is helpful,
After a couple of find/grep cycles, I also found that
G4MTRunManager::AbortRun() itself calls
G4MTRunManagerKernel::BroadcastAbortRun(), which does what I was hoping it would do.
I also managed to track down my original problem. It turns out that we were calling a beginning-of-run-only “open the new file” action on every event! That meant that the other threads, after one of them hit EOF, reopened the file and started again. I’m not sure why they didn’t get the AbortRun() signal, which means I’ve got two issues to fix.