1 / 13

Thread-safety and shared geometry data

Thread-safety and shared geometry data. J. Apostolakis. Overview. Issues RW data in the ‘live’ geometry tree Causes Implications Improving Geometry for MT !? Reducing / eliminating RW data Impact on kernel and user code Expected and potential changes. Issues.

gwen
Download Presentation

Thread-safety and shared geometry data

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Thread-safety and shared geometry data J. Apostolakis

  2. Overview • Issues • RW data in the ‘live’ geometry tree • Causes • Implications • Improving Geometry for MT !? • Reducing / eliminating RW data • Impact on kernel and user code • Expected and potential changes

  3. Issues • Live geometry tree has ‘read write’ members • Physical Volumes – identify the copy number • PVReplica: intCopyId • PVParameterisedVolume: VSolid, Transformation, .. • This means that today the RW fields must be thread local in G4-MT • Can we make G4Navigator + Geometry ‘independent’ and fully thread-safe ?

  4. What is RW in geometry? • In the LIVE geometry tree most Physical Volumes types are RW (except Placement) • Why? To address need to identify the copy number, and to have the correct properties • Specifically • PVReplica: intCopyId • PVParameterisedVolume: VSolid, Transformation, Material, ..

  5. Explanation Logical View – Replica or Parameterised Volume 1 2 3 4 5 View in Memory – Geant4 objects Physical B Logical B Paramor Replica PV Logical Mate-rial Copy#

  6. Who uses the RW information? • Every client of the geometry • G4VPhysicalVolume GetLogicalVolume() • G4LogicalVolume GetSolid() • G4LogicalVolume GetMaterial() • G4Processes • Any process that needs • User code – in Sensitive Detector, Actions, …

  7. Implications • This means that today all the RW fields must be thread local in G4-MT • A mini-class is required to hold CopyId for Replica • Each Replica instance gets an InstanceId, and references a location in Local Array • Extra indirection + needs to use thread Id (worker?) • Parameterised volumes have special way • A copy of each PV instance is created in master • Threads create a copy of each instance • Result: lessmemory savings; Unclear whether RegularNavigation will work.

  8. Impact • Each solid must have a Clone() method • A worker (thread) must create a clone of each solid of the Parameterised Volume • Can be thousands or millions • This solution greatly reduces reuse of memory in MT • Clear impact on applications with large Param. Vol. • Unclear whether NestedParameterisation and Regular Navigation work or not • Alternative solution could / should be sought

  9. Tentative Plans • Goal: Reduce or eliminate RW information in ‘live’ geometry tree • Keep all information about current volume only in G4TouchableHistory • Can it be done without breaking interfaces? • Challenge: What about existing uses of key methods? • in PhysicalVolume->GetLogicalVolume • logicaVolume->Get(Solid,Material, ..)

  10. Change: internal in Geometry • Keep all information about current volume only in G4TouchableHistory • Requires changes in G4Navigator and its dependent classes • Additional information to be kept in Touchable History (tbc) • If we need to maintain interface(s) of PV, LV, • Change interface of Parameterised Volume and Parameterisation ? • Create a clone of logical volume (?)

  11. Changes: users’ considerations • If we do not keep compatibility all calls to GetLogicalVolume->Get(Solid, …) • Must migrate much kernel and user code • Some of this code is already wrong (must use TouchHist to get correct answer). • How to solve uses of Physical/Logical Volume Get methods ? • Can ‘local’ clones of LogicalVolume solve this ?

  12. Use in Tracking – after relocation Logical View – Replica or Parameterised Volume 1 2 3 4 5 View in Memory – Geant4 objects Physical B Logical B Paramor Replica PV Logical Mate-rial Copy:5

  13. Additional issues • Must associate correct Thread-local Field to the relevant LogicalVolume (or Region). • The locations of these fields are: • Global (all space) – belongs to World log-vol; • Per Region – belong to region; • Per Logical Volume – to LV. • Must ensure correct assignments • Note that LV has a FieldManager = field + ‘Solver’

More Related