[ https://issues.apache.org/jira/browse/ARROW-16498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Weston Pace reassigned ARROW-16498: ----------------------------------- Assignee: Weston Pace > [C++] Fix potential deadlock in arrow::compute::TaskScheduler > ------------------------------------------------------------- > > Key: ARROW-16498 > URL: https://issues.apache.org/jira/browse/ARROW-16498 > Project: Apache Arrow > Issue Type: Bug > Components: C++ > Reporter: Weston Pace > Assignee: Weston Pace > Priority: Major > Labels: pull-request-available > Fix For: 9.0.0 > > Time Spent: 50m > Remaining Estimate: 0h > > An extremely simplified version of the task scheduler's ScheduleMore method > it looks something like: > {noformat} > void ScheduleMore(int num_to_schedule) { > tasks_that_need_running_.fetch_add(num_to_schedule); > if (!weak_lock.lock()) { > // If someone else is scheduling then return early > return; > } > auto tasks = PickTasks(); > weak_lock.unlock(); > } > {noformat} > It is possible for one thread to have the lock, and find 0 tasks. But then, > before it gives up the lock, another thread adds tasks and fails to acquire > the lock. Neither thread will schedule anything even though there are tasks > to run. This can lead to deadlock. > The proposed PR changes the logic to (still extremely simplified): > {noformat} > void ScheduleMore(int num_to_schedule) { > tasks_that_need_running_.fetch_add(num_to_schedule); > tasks_added_recently.store(true); > if (!weak_lock.lock()) { > // If someone else is scheduling then return early > return; > } > auto tasks = PickTasks(); > if (tasks_added_recently.compare_exchange_strong(true, false)) { > if (tasks.empty()) { > ScheduleMore(); > } > } > weak_lock.unlock(); > } > {noformat} -- This message was sent by Atlassian Jira (v8.20.7#820007)