forked from stpaine/FERS
-
Notifications
You must be signed in to change notification settings - Fork 1
Core Thread Pool
David Young edited this page Apr 30, 2025
·
2 revisions
A fixed-size thread pool (pool::ThreadPool) is implemented to manage a collection of worker threads. It allows tasks (represented as functions or callable objects) to be enqueued and executed asynchronously by the available worker threads. Standard C++ synchronization primitives (mutexes and condition variables) are used internally to manage the task queue and coordinate worker threads. The pool supports submitting tasks and provides a mechanism to wait for all currently enqueued tasks to complete execution.
- Assumes that tasks submitted to the pool are independent, or if they access shared data, that synchronization is handled correctly outside the thread pool mechanism (e.g., within the tasks themselves or via data structure design).
- Assumes the underlying standard C++ library implementations of
std::thread,std::mutex,std::condition_variable, etc., behave correctly according to the standard. - Assumes that the typical execution time of submitted tasks is sufficiently long relative to the overhead of queuing, scheduling, and context switching for parallel execution to provide a performance benefit.
- Assumes that any exceptions potentially thrown by submitted tasks should be caught and handled (e.g., logged) within the worker thread's execution loop to prevent thread termination.
- Fixed Size: The number of worker threads in the pool is fixed upon creation and cannot be dynamically adjusted during runtime.
-
Basic Exception Handling: The pool's worker loop includes basic exception catching (
try...catch(...)) primarily to log errors and prevent worker thread crashes, but it does not propagate exception information back to the submitter. -
Estimated Availability: The
getAvailableThreads()method provides only an estimate of idle threads at a specific moment, which might change immediately after the call. - No Prioritization: There is no mechanism to prioritize tasks; tasks are typically processed in a roughly First-In, First-Out (FIFO) order from the queue.
- Source Files:
thread_pool.h,thread_pool.cpp - Uses standard library components:
std::thread,std::mutex,std::condition_variable,std::queue,std::function. - Utilized by: Concurrency features like Parallel Simulation (Pairs) and Parallel Window Rendering (HDF5).
- Needs Verification: The basic functionality (task submission, execution, waiting) is implicitly tested by its use in other parallelized parts of the simulation. However, the pool itself hasn't undergone specific stress testing or formal verification.
-
Key Areas for Validation:
- Correctness under high load (many tasks submitted rapidly or concurrently).
- Absence of deadlocks or race conditions within the pool's internal queue management and synchronization logic.
- Performance scaling characteristics (how throughput changes with thread count for typical FERS tasks).
- Robustness of the exception handling within the worker loop (ensuring it logs appropriately and doesn't crash).
- Behavior when tasks have significantly varying execution times.
- Priority: Medium (As core infrastructure, stability is important, but specific validation might be secondary to validating the simulation logic it enables unless performance/stability issues arise).