oneapi-src
WIP: Flow Graph - remove C++03 legacy
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
- [x] needs to be updated
- [ ] not needed
Breaks backward compatibility
- [x] Yes
- [ ] No
- [ ] Unknown
Notify the following users
List users with @ to send notifications
Other information
@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.
@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.