forked from stpaine/FERS
-
Notifications
You must be signed in to change notification settings - Fork 1
Parallel Rendering (Receivers)
David Young edited this page Apr 30, 2025
·
1 revision
After the main simulation phase completes (where all Transmitter-Receiver pair interactions are calculated), this concurrency feature parallelizes the generation of output files for each receiver. The runThreadedSim function iterates through all configured Receiver objects. For each receiver, it enqueues a task (receiver->render()) onto the shared thread pool. This render task is responsible for generating the receiver's specific output files (XML, CSV, HDF5). The main simulation thread then waits (pool.wait()) until all these receiver rendering tasks have completed before finishing the simulation run.
- Assumes that the
Receiver::renderoperation for one receiver is completely independent of therenderoperation for any other receiver. They do not share or modify common data in conflicting ways during this phase. - Assumes that the underlying file system operations and library calls (like standard file I/O and HDF5 library functions) are thread-safe when multiple threads write to different files concurrently.
- Assumes the
Receiver::_responsesvector (containing the results from the simulation phase) is not modified by any thread after the simulation phase'spool.wait()completes and before the rendering phase starts.
- Scalability Limit: The maximum parallelism achievable is limited by the number of receivers defined in the simulation scenario. If there are fewer receivers than available threads in the pool, some threads will remain idle.
- Performance Limit: Potential for Input/Output (I/O) bottlenecks. If many threads attempt to write large output files simultaneously, performance may be limited by disk speed or file system contention, reducing the benefits of parallelization.
-
sim_threading.cpp::runThreadedSim(Orchestrates the overall simulation flow, including this parallel phase) -
receiver.cpp::Receiver::render(The main function executed as a task for each receiver) -
receiver_export.cppfunctions (e.g.,exportReceiverXml,exportReceiverCsv,exportReceiverBinarycalled byReceiver::render) -
pool::ThreadPool(The core thread pool managing worker threads and the task queue) -
Receiverclass (Represents the receiver entity and holds its data)
-
Needs Verification: The core assumptions regarding thread safety and independence need confirmation. Specifically, the thread safety of concurrent file writes (especially HDF5 if configured inappropriately or if the underlying library has issues) and the strict independence of
Receiver::rendercalls. -
Key Areas for Validation:
- Verify output file integrity and correctness when generated concurrently for multiple receivers, especially for complex formats like HDF5.
- Test for potential race conditions during file writing or access to shared resources (if any exist beyond the assumptions).
- Measure performance scaling: does increasing the number of threads significantly decrease total rendering time for scenarios with many receivers? Identify potential I/O bottlenecks.
- Ensure no deadlocks or unexpected behaviour arise from using the thread pool for this phase.
- Priority: Medium