Some planning setups require that a planner be made for each thread and maintained. For example, with my current DART + Robowflex setup, I need to interact with the underlying DART scene for different queries.
This limits my ability to parallelize benchmarking as I need to enforce that each worker thread only interacts with its respective planner. I've got a workaround for the time being, but it would be nice to have the ability to queue runs in the Experiment API and assign them to a particular worker thread.
Detailed Description
Allow requests to be queued in an Experiment and assigned to a particular thread.
Possible Implementation
The current implementation accents a number of worker threads in the Experiment::benchmark (std::size_t n_threads=1) method. Instead, this param would need to be accepted in the constructor, and the various Experiment::addQuery methods be changed to accept a thread index to queue the job to.
Under the hood, the queued jobs will need to be indexed by their assigned thread. Currently, the Experiment::benchmark method has each thread grab a mutex lock, pop a job to run from the queue, and unlock. If the jobs are already indexed by their worker thread, each thread can pop a job off its queue without worrying about synchronization.
This would leave the burden of dividing the jobs up by thread to the user. However, I think this might be useful in fringe situations like what I'm dealing with.
Some planning setups require that a planner be made for each thread and maintained. For example, with my current DART + Robowflex setup, I need to interact with the underlying DART scene for different queries.
This limits my ability to parallelize benchmarking as I need to enforce that each worker thread only interacts with its respective planner. I've got a workaround for the time being, but it would be nice to have the ability to queue runs in the
ExperimentAPI and assign them to a particular worker thread.Detailed Description
Allow requests to be queued in an Experiment and assigned to a particular thread.
Possible Implementation
The current implementation accents a number of worker threads in the
Experiment::benchmark (std::size_t n_threads=1)method. Instead, this param would need to be accepted in the constructor, and the variousExperiment::addQuerymethods be changed to accept a thread index to queue the job to.Under the hood, the queued jobs will need to be indexed by their assigned thread. Currently, the
Experiment::benchmarkmethod has each thread grab amutexlock, pop a job to run from the queue, and unlock. If the jobs are already indexed by their worker thread, each thread can pop a job off its queue without worrying about synchronization.This would leave the burden of dividing the jobs up by thread to the user. However, I think this might be useful in fringe situations like what I'm dealing with.