-
Notifications
You must be signed in to change notification settings - Fork 542
Open
Description
We are using a rayon thread pool to run a rust-based userspace driver. A mutex must be acquired before calls can be made to the driver.
We are running into a common deadlock problem with rayon work-stealing.
This issue occurs because the third party code that invokes our driver is also using rayon.
The deadlock results from the following events:
- Third party global thread pool is running N jobs
- Third party thread A invokes our library
- Third party thread A acquires our driver mutex
- Third party thread A creates a scope within our driver thread pool
- Third party thread A steals work
- Third party thread A invokes our library
- Third party thread A is waiting on a lock that it already holds.
- Deadlock
The rayon thread pool API fits our use-case perfectly, but the implementation detail of work-stealing causes deadlocks.
Is there an easy way to modify the thread pool internals to prevent work-stealing?
I'm not looking to merge with upstream unless this feature is wanted by others. I'd be OK with maintaining a non-work-stealing fork if a maintainer could give me some tips for how to do this.
marksieklucki
Metadata
Metadata
Assignees
Labels
No labels