[jira] [Assigned] (ARROW-12902) [C++] Create work stealing implementation of generalized ThreadPool

["Todd Farmer (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARROW-12902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Todd Farmer reassigned ARROW-12902:
-----------------------------------

    Assignee:     (was: Weston Pace)

This issue was last updated over 90 days ago, which may be an indication it is no longer being actively worked. To better reflect the current state, the issue is being unassigned. Please feel free to re-take assignment of the issue if it is being actively worked, or if you plan to start that work soon.

> [C++] Create work stealing implementation of generalized ThreadPool
> -------------------------------------------------------------------
>
>                 Key: ARROW-12902
>                 URL: https://issues.apache.org/jira/browse/ARROW-12902
>             Project: Apache Arrow
>          Issue Type: Sub-task
>          Components: C++
>            Reporter: Weston Pace
>            Priority: Major
>
> Given the chase-lev deque and the generalized thread pool we are now able to create a work stealing version.  This issue forces us to address some thorny issues that don't concern academic thread pools.
> For example, we need to allow tasks for the thread pool to be submitted from outside the thread pool itself.  An academic work-stealing thread queue has one queue per thread and each thread adds incoming tasks to its own queue.  If the task adding queue isn't in the thread pool then it doesn't have a queue.  This is a tricky issue because it implies a queue with multiple producers and multiple consumers.
> There's a couple of ways to tackle this but generally it means that the work stealing thread pool is going to have to rely on locking in a number of places.  Ideally the hot path can be kept lock free.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)