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)