Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
2466 Discussions

Compiler error: try_put call is ambiguous (tbb::flow) EDIT: SOLVED

ahelwer
New Contributor I
519 Views
I have created the following simple program:
[cpp]#include #include class Body { public: std::string m_name; Body(std::string name) : m_name(name) { } void operator() (tbb::flow::continue_msg) const { printf("%s\n", m_name.c_str()); } }; int main() { tbb::flow::graph g; tbb::flow::continue_node<:FLOW::CONTINUE_MSG> start(g, Body("Start")); start.try_put(tbb::flow::continue_msg()); return 0; }[/cpp]
However, when compiled with icc I get the following error:

flow.cpp(16): error: "tbb::flow::interface6::continue_node::try_put [with Output=tbb::flow::interface6::continue_msg]" is ambiguous
start.try_put(tbb::flow::continue_msg());
^
compilation aborted for flow.cpp (code 2)

This is for the version of TBB that comes with Composer XE 2011 sp1.9.293. Why does this happen? It compiles just fine on other versions - specifically, it compiles with Composer XE 2011 sp1.6.233.

EDIT: I managed to find the problem.

Turns out when you're calling try_put on a continue node in the newest version of tbb, you have to specify that it's the continue_receiver try_put function you want. It conflicts with one of the other classes continue_node inherits from (not sure which one). So the call on line 16 looks like this:
[bash]start.tbb::flow::continue_receiver::try_put(tbb::flow::continue_msg());[/bash] Looks really ugly. I guess Intel is trying to say not to explicitly call try_put on continue nodes?
0 Kudos
2 Replies
Christophe_H_Intel
519 Views
Hello, ahelwer,

Thanks for reporting the error. Part of the recent implementation of the multifunction_node involved factoring the function_node to reuse the code in the output array. This resulted in an extra overload of try_put for all nodes using the function_node output. (We wanted the same name, try_put(), to work with the output from multifunction_node.)

The test case for the continue_node did not detect the ambiguity because it used an explicit cast of the continue_node tothe receiver type that resolved it, so I didn't detect the error until shortly before the most-recent release (too little time to add the fix.)

The workaround is just what you discovered (explicit reference to receiver).

Regards,
Chris Huson
0 Kudos
Christophe_H_Intel
519 Views
Hello, ahelwer,

One additional note: just executing a try_put() to a node will cause tasks to be enqueued and executed. You might notice the test program gets a segmentation fault.

Because tasks are enqueued, you must execute

g.wait_for_all();

to ensure all the tasks complete before the end of the main program.

Regards,
Chris
0 Kudos
Reply