Skip to content

Thread pool without work stealing #1174

@nhukc

Description

@nhukc

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:

  1. Third party global thread pool is running N jobs
  2. Third party thread A invokes our library
  3. Third party thread A acquires our driver mutex
  4. Third party thread A creates a scope within our driver thread pool
  5. Third party thread A steals work
  6. Third party thread A invokes our library
  7. Third party thread A is waiting on a lock that it already holds.
  8. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions