You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@arrow.apache.org by "Weston Pace (Jira)" <ji...@apache.org> on 2021/05/28 03:11:00 UTC

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

Weston Pace created ARROW-12902:
-----------------------------------

             Summary: [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
            Assignee: Weston Pace


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.3.4#803005)