Home > Program > Session 7 > Hands-on

Hands-on

Migrate the exampleED application to MT. After each step rebuild the program. You can also try to run and observe the behaviour (breaks) after each step and understand how the next step fixes the observed break. Steps:
1. Update the main function: add G4RunManagerFactory.
2. Update the ActionInitialization class: add the BuildForMaster() function.
3. Update the Hit classes: declare G4Allocator thread local.After these steps the migration is complete. Rebuild and rerun the program.
Increase the number of events (~300) and observe the ROOT output. Inspect the ntuple files generated per threads. Active ntuple merging, run the same number of events and observe the ROOT output again.

Change the default number of threads: first in the code and then via the environment variable. Observe which setting has the preference.
Limit the output to one thread only (via a command in a macro).
Get an experience with a data race. Add a global variable defined in a file scope in ChamberSD.cc just after the headers in commented lines:
```
G4double* myGlobalValue = new G4double(1.);
```
and in ChamberSD::ProcessHits():
```
// simulate data race 
if ( (*myGlobalValue) > 0.) { 
  delete myGlobalValue; 
  myGlobalValue = new G4double(-1); 
} else { 
  delete myGlobalValue; 
  myGlobalValue = new G4double(1); 
}
```
Run the program in batch mode. Does the program break now? Congratulation, the race condition was added successfully ! Use G4AutoLock to fix this thread-unsafe code.

Implement the newly added command-line option [-g gdmlFile] in the main program: when the GDML file is provided export the geometry in GDML.

Hint: The world volume can be accessed in main in this way:

G4LogicalVolume* world = G4TransportationManager::GetTransportationManager() ->  GetNavigatorForTracking()->GetWorldVolume()->GetLogicalVolume());