problems using parallel_do

problems using parallel_do

I'm trying to use parallel_do (using tbb20_20080226oss), but I'm getting an error from the compiler (MS VC++ 2005). I am trying to process some data in a simple structure maintained in a list:

typedef struct {
double v1, v2, v3;
} my_item_t;

typedef list vec_list;

class Body{
public:
typedef my_item_t argument_type;
Body() {};
// overload () so it does a vector multiply
void operator() (argument_type& it) const {
it.v3 = it.v1 * it.v2;
}
};

The () operator takes a reference to the simple structure as shown in the documentation for parallel_do. However, the compiler cannot find a () operator that matches the prototype it wants. If I change the operator by removing the reference, then it compiles with no errors:

void operator() (argument_type it) const {
it.v3 = it.v1 * it.v2;
}

But this doesn't work because any changes made by the operator only occur in the local copy and don't get passed back into the main list.

I can get around this problem by making a list of pointers that point to the data structures, but it seems like the code shown above should work and I want to understand where I'm making my mistake.

Thanks for any enlightenment anyone can give.

4 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Thank you for reporting the problem.

The documentation is in fact incorrect. The implementation of parallel_do may copy processed itemsduring its work, this is why there are requirements for argument_type to have a copy constructor and a destructor. Obviously it does not make sense for operator() to take the reference to an item if that reference can point to an internal copy and not to the original item.

I apologize for our documentation misleading you.

Alexey:

Thank you for taking the time to reply to my question.

Based on your answer, can I assume that the proper way to process items using parallel_do is for the argument_type to contain a pointer where the () operator can store any results that are computed? I can't see any other way to get results out of (). Am I missing something really obvious?

Yes, it seems for the moment it's your best resort. I have initiated a discussion about extending parallel_do semantics the way you need, but this will take time and perspectives aren't clear.

Leave a Comment

Please sign in to add a comment. Not a member? Join today