Message: Re: G4VPhysicalVolume->GetTranslation() from threads Not Logged In (login)
 Next-in-Thread Next-in-Thread
 Next-in-Forum Next-in-Forum

Idea Re: G4VPhysicalVolume->GetTranslation() from threads 

Forum: Multithreading
Re: Question G4VPhysicalVolume->GetTranslation() from threads (Jan Pipek)
Date: 07 Apr, 2016
From: Andrea Dotti <Andrea Dotti>

Hello Jan,

Some classes including geometry ones (the so called "split classes", see http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/ForToolkitDeveloper/html/ch02s14.html#sect.DsgnFuncMT.MemHand) have some data-members that use thread-local-storage technology.

When a thread starts these TLS storage needs to be properly initialized. Since you do not do that in your own thread, this causes the TLS storage pointers to be all invalid pointers and thus the crash you observe.

There may be a possible solution to this, but I never tried it and I am not sure that this will work correctly, you will have to try it out...

When your thread is created you should call some special kernel functions that will setup the pointers of geometry. You can find these calls in the function implemented at line 57 of: http://www-geant4.kek.jp/lxr/source/run/src/G4WorkerThread.cc Try to put these lines in your thread creation before you do anything else. To do a clean exit you need to implement at exit of the thread what is shown at line 70. There is a special case, if you have a single job with multiple runs (e.g. multiple /run/beamOn commands) and you change geometry between the runs. This is non trivial and is shown at line 101. I am not sure how from your special thread you can detect a change of geometry and a new run, though. I hope that you do not have to cover this use-case, because it would complicate quite a lot the code.

Finally, I suggest you to setup additional stuff in your special thread. In particular you can look at the function implemented at line 105 of http://www-geant4.kek.jp/lxr/source/run/src/G4MTRunManagerKernel.cc this is the thread function for workers in Geant4. I suggest you implement at least:

A) Step-0, using as thread ID the enum value: G4Threading::GENERICTHREAD_ID or any negative number of your choice smaller than -1000. It is very important that the ID is negative (positive numbers are reserved for workers, i.e. thread that perform simulation, 0 is master)

B) If you expect to use random numbers in your special thread, you need also Step-1

C) The really important part is Step-2, where the initialization of "split classes" is done.

D) Step-7 is a good practice

Please note you are here dealing with many non-trivial Geant4 internal stuff and MT is not a simple matter... I strongly suggest you to go through chapter 2.14 of our Toolkit Developer Guide (http://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/ForToolkitDeveloper/html/ch02s14.html), you should get familiar with G4 threading model and you may found there many utilities/classes that can be useful for you.

Andrea

 Add Message Add Message
to: "Re: G4VPhysicalVolume->GetTranslation() from threads"

 Subscribe Subscribe

This site runs SLAC HyperNews version 1.11-slac-98, derived from the original HyperNews