Parallel Simulation (Pairs)

Description

The main simulation loop (runThreadedSim) iterates through all unique Transmitter-Receiver pairs defined in the simulation scenario. For each pair, it enqueues a simulatePair task onto the core thread pool (pool::ThreadPool). The system then waits (pool.wait()) until all these pair simulation tasks have completed before proceeding to the next stage (e.g., output rendering). This allows the computationally intensive parts of simulating interactions (target returns via solveRe, direct paths via solveReDirect) for different Tx/Rx pairs to potentially run concurrently.

Assumptions

• Receiver::addResponse uses a mutex (std::lock_guard), ensuring thread-safe writes when multiple threads add results to the same receiver's response list.
• Assumes that methods called within the simulatePair task (e.g., platform getPosition, antenna getGain, target getRcs) are thread-safe for concurrent read operations, or that the data they access (like platform positions or antenna patterns for a given time step) is effectively immutable during this parallel phase.
• Assumes correct C++ object lifetime management prevents dangling pointers or use-after-free issues for objects accessed by concurrent tasks (e.g., Platforms, Radars, Targets).

Limitations

• Scalability: Performance improvement depends directly on the ratio of the number of Transmitter-Receiver pairs to the number of available worker threads in the pool. If the number of pairs is small relative to the thread count, the benefit of parallelism may be limited.
• Mutex Contention: Minor performance bottlenecks might occur due to contention on the Receiver::_responses_mutex if many threads attempt to add simulation responses to the same receiver simultaneously (e.g., a single receiver interacting with many transmitters or targets concurrently within the same time window).

Related Components

• Orchestration: sim_threading.cpp::runThreadedSim
• Core Task Logic: sim_threading.cpp::simulatePair
• Sub-Tasks: sim_threading.cpp::simulateTarget, sim_threading.cpp::addDirect
• Physics Calculations: solveRe, solveReDirect
• Concurrency Mechanism: pool::ThreadPool::enqueue, pool::ThreadPool::wait
• Result Aggregation: Receiver::addResponse
• Synchronization: std::mutex, std::lock_guard (within Receiver::addResponse)
• Wiki Pages: Concurrency, Core Thread Pool, Core Simulation Physics

Validation Status

• Needs Verification: While simulations run to completion using this mechanism, rigorous verification of correctness under concurrency and the absence of subtle race conditions is essential.
• Key Areas for Validation:
  • Race Condition Detection: Employ thread sanitizers (e.g., TSan with Clang/GCC) during testing to actively detect potential data races, particularly in read operations assumed to be safe.
  • Result Consistency: Ensure that final simulation outputs (e.g., generated HDF5, XML, CSV files) are bit-for-bit identical across multiple runs of the same scenario when varying the number of worker threads (e.g., 1 thread vs. N threads). This confirms that concurrency does not introduce numerical errors or state corruption.
  • Performance Scaling Analysis: Measure simulation execution time with varying numbers of threads for scenarios with different complexities (few pairs vs. many pairs) to quantify the actual performance benefits and identify potential bottlenecks (like mutex contention).
  • Stress Testing: Execute scenarios designed to maximize contention (e.g., many transmitters interacting with a single receiver) to evaluate the robustness of the mutex synchronization.
• Priority: High (Concurrency bugs can significantly impact simulation reliability and correctness, and are often difficult to diagnose).