Implementation of task_group dynamic dependencies - part 4 - support for task cancellation

[kboyarinov]

Description

Improve function_task::cancel to propagate the cancellation signal

Fixes # - issue number(s) if exists

Type of change

Choose one or multiple, leave empty if none of the other choices apply

Add a respective label(s) to PR if you have permissions

• bug fix - change that fixes an issue
• new feature - change that adds functionality
• tests - change in tests
• infrastructure - change in infrastructure and CI
• documentation - documentation update

Tests

• added - required for new features and some bug fixes
• not needed

Documentation

• updated in # - add PR number
• needs to be updated
• not needed

Breaks backward compatibility

• Yes
• No
• Unknown

Notify the following users

List users with @ to send notifications

Other information

[akukanov]

The tradeoff is not obvious. Spawning carries some overhead but allows finalization to be done by multiple threads. And we cannot predict how many tasks are there for finalization. Perhaps some experimentation is needed to see how many (in the order of magnitude) tasks are needed for the break-even point between the two approaches.

[akukanov]

In the case of cancellation, do we even need to preserve the dependencies? Can the dependency counting to be fully skipped, and instead some marker in task_dynamic_state put in place of the task pointer to indicate that the task has been taken for cancellation?

[kboyarinov]

It seems like this is not that straightforward to implement. Consider submitting the predecessor task_handle and not submitting the successor handle with the cancelled execution.
Since there are not dependencies for the predecessor task, it would be cancelled by the scheduler. Yes, we can mark the successor list of the predecessor as completed (or using the special flag), but what should we do with the successor list.
I don't think that cancelling all of the tasks without dependency counting is a good idea, since the successor would be cancelled before being submitted for execution in this case.

[kboyarinov]

By the way, the "correct" support for cancellation needs to be reconsidered in a similar way with the partial graph destruction. Imagine cancelling some of the tasks and then resetting the task_group_context.
The idea of this patch is to avoid hangs on waiting if the execution is cancelled as a "preliminary" support for cancellation.

[akukanov]

So, we have more open questions to add to the design RFC it seems.

[vossmjp]

Same double setting of m_innermost_running_task issue.

[kboyarinov]

Rebased to part1 after merging the transferring support. Resolved.

[vossmjp]

I would suggest (at some point) adding a test that runs at least some part of the task graph before the task_group is canceled. So probably, cancel from within a task at an intermediate level.