Multi-threaded examples
This merge request depends on !15 (merged) and should not be merged in before the later is approved and a rebase is carried out. Moreover, it changes the test framework's design in a couple of ways, and we should discuss these changes before merging them in.
It fixes ACTSFW-9 by making all ACTSFW examples multithreaded and greatly easing the task of writing more multithreaded examples in the future. The multi-threading strategy that is used is to process different events in parallel. This is similar to the approach used in CMSSW and Gaudi/AthenaMT, and should thus allow us to catch many kinds of thread-safety issues affecting these frameworks.
One kind of issue that can exist in Gaudi, but we will not catch, are those triggered by the concurrent invocation of several algorithms on the same event, such as EventStore data races. That is because algorithm-level parallelism would require a lot more framework changes, such as the introduction of data dependencies management or the synchronization of whiteboard accesses, for a more limited gain in test setup realism. I did not think it would be worthwhile.
Doing this work cleanly and in a future-proof fashion required a couple of framework design changes:
- To be safely callable from multiple threads, algorithms no longer carry event-specific state such as an EventStore pointer in their data members. Instead, that information is passed in by the framework as a parameter to execute(). This is similar to the EventContext approach used by Gaudi.
- The event store is no longer shared between events. Instead, each event in flight gets a private event store. This change is required to make ACTFWWhiteBoardExample thread-safe.
- Example algorithms no longer rely on a shared random number generator, as it is very hard to make this design work in a reproducible and efficient manner. Instead, RandomNumbers has been extended into a service, RandomNumbersSvc, which is able to spawn a reproducibly seeded thread-private RNG for each algorithm in flight.
- RootExCellWriter is now mutex-protected, in order to work well when called by multiple writer threads concurrently.