WIP: Flow Graph - remove C++03 legacy

[kboyarinov]

Description

Rewrite Flow Graph join_node and indexer_node to use variadic templates.
Follow up for #437

Fixes # - issue number(s) if exists

• - git commit message contains an appropriate signed-off-by string (see CONTRIBUTING.md for details)

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

[knoepfel]

What is the status of this PR?

[kboyarinov]

@lin72h @knoepfel

Thank you for expressing your interest into this PR.
Current status of this change for us is a low priority enhancement of the FG implementation and there are still things that should be investigated, e.g., backward compatibility.
Could you please share your use cases that finds this change useful if any? It would be very helpful for pushing this activity forward.

[knoepfel]

@kboyarinov, thanks for reaching out. I have been using oneTBB flow for a while, and have greatly enjoyed it. One of the use cases I have is that some algorithms/nodes invoke library code that is not thread-safe. It is not sufficient to simply specify a concurrency level of 1 for that node, because there are other nodes that might also call the same library at the same time. Instead, for nodes that have to call the same thread-unsafe resource, I use a join node where one of the input ports receives a serialization token--only one token exists in the full graph for a given thread-unsafe library, and the node will not execute until it receives the token. And sometimes more than one token is required if there are more than one thread-unsafe libraries that must be invoked by the node.

I also use join nodes, though, with tag-matching to ensure that all of the arguments required by a particular algorithm are available before the algorithm is executed. If the algorithm requires $m$ serialization tokens, with the current implementation of the join node, that leaves $10-m$ ports for algorithm arguments. Hopefully, an algorithm will not need a significant number of serialization tokens, and a large number of algorithm arguments, but with the current implementation, I have to think about the 10-port max restriction, instead of just letting the compiler specify a maximum number of arguments as allowed in a variadic parameter pack.

Does that help explain the situation? I can also produce a diagram if that would be helpful.