Fix the allocator for Flow Graph critical tasks creating

[kboyarinov]

Description

There is a bug in the current implementation of Flow Graph while using functional node concurrency limits together with node priorities.
Current algorithm for creating tasks in function node is the following:

• If the concurrency limit is not reached, two tasks are created - graph_task for executing the body and priority_task_selector task for prioritization. Both tasks are created by the same thread.
• If the concurrency limit is reached, the postponed items are stored in the queue.
• Once the resources of the node are available, the thread X tries to get the postponed item from the queue using the aggregator.
• Since the aggregator is used, another thread Y can take the "aggregated" work and hence, create the graph_task using its small object pool.
• Once the control goes back to thread X, it creates a priority_task_selector wrapper. The bug in the current implementation is that the small object pool, associated with the underlying task (created by thread Y) is used instead of small object pool of thread X.

Also this patch adds extra assert for small object pool to ensure that the pool, for which the allocation is requested is the same as the TLS pool.

Fixes #1595

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

[aleksei-fedotov]

I wonder if we can make the test more lightweight.

How reproducible is this? From what I've understood the task should go into the node's queue in order to reproduce the behavior. Maybe, we can decrease the num_iterations at the expense of increasing the amount of compute done in node's body using some useless work pattern such as putting thread to sleep or introducing empty loop which is not elided by the compiler. IMHO, that would induce less pressure on the system. But will it still be reproducible enough?

[kboyarinov]

I will investigate if it is possible to change the test to make it more lightweight.
As far as I understand, the root cause of the issue is the aggregator of function_node and we need to maximize the pressure on the aggregator to increase the chance that one thread will request creating of the task, another thread will create it under the aggregator and return the control to the first thread. So I am not sure that increasing or blocking the node body would help.

[aleksei-fedotov]

At the very least I would add a comment why it is necessary, explaining why graph_task's allocator cannot be used here. After all, its purpose is to cache allocations. BTW, if it cannot be used, do we need to have it in graph_task at all?

[kboyarinov]

Sure, I agree that the comment is required.
Regarding the necessity of the allocator inside of the graph_task, it is required not only for allocating the critical tasks, but also for deallocation of the graph_task itself after the execution (even in the case without critical tasks).