Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Add per-thread queuing for benchmarking #302

Open
ell0ry opened this issue Oct 28, 2022 · 1 comment
Open

[FEATURE] Add per-thread queuing for benchmarking #302

ell0ry opened this issue Oct 28, 2022 · 1 comment
Assignees
Labels
enhancement New feature or request

Comments

@ell0ry
Copy link
Collaborator

ell0ry commented Oct 28, 2022

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.

@ell0ry ell0ry added the enhancement New feature or request label Oct 28, 2022
@ell0ry ell0ry self-assigned this Oct 28, 2022
@ell0ry
Copy link
Collaborator Author

ell0ry commented Oct 28, 2022

Because this change requires that data structures and function signatures inside the Experiment class be changed, I'll need to copy it instead of extending it. For now, I'm going to work on a pull request that implements a cloned and updated ThreadedExperiment class in the same source file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant