parallel_do requires copiable items, and parallel_for_each inherits this limitation

parallel_do requires copiable items, and parallel_for_each inherits this limitation

Ritratto di Stefano P.
Stefano P.
Mar, 04/12/2012 - 10:27

Hi,

suppose we have a container C of objects T, C<T> and T is non-copiable, deriving from boost::noncopiable, and some tbb::parallel_do calls:

C<T> container;
tbb::parallel_do(container.begin(), container.end(), ...);

or suppose we have an abstract base class B:

boost::ptr_vector<B> container;
tbb::parallel_do(container.begin(), container.end(), ...);

These don't compile as Item, so T or B, is copied in do_iteration_task, there is an "Item my_value". It should be "Item& my_value" but I understand this violates the whole design, as you can feed objects to a tbb::parallel_do while it's still running so objects must (?) be part of internal tasks. I'm not a big fan of that but fine, even if I haven't spotted this limitation in any documentation.

BUT this doesn't justify tbb::parallel_for_each to fail. It's currently implemented using tbb::parallel_do that has this constraint, so you cannot use it with non-copiable items or complex containers like boost::ptr_* BUT tbb::parallel_for_each doesn't need to copy object.

Can we have it reimplemented in terms of tbb::parallel_for? Or possibly have the limitation in tbb::parallel_do removed?

At affects al least any TBB version <= 4.1.

Thank you.

Stefano

RSS In cima
5 post / 0 new
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione
Ritratto di jimdempseyatthecove
jimdempseyatthecove
Mer, 05/12/2012 - 05:24

Consider:
C container;

tbb::parallel_do(container.begin(), container.end(), [&]{ });
or
tbb::parallel_do(container.begin(), container.end(), [&container]{ });

Jim Dempsey

Blog: The Parallel Void

www.quickthreadprogramming.com
In cima
Ritratto di Stefano P.
Stefano P.
Mer, 05/12/2012 - 06:19

Yes, ok, the lambda were wrong, but the point is still valid.

In cima
Ritratto di jimdempseyatthecove
jimdempseyatthecove
Gio, 06/12/2012 - 14:48

Don't pass the container entries by value, pass by reference or pointer, or {container reference/pointer and index}.

If you do not want copy operators (or can't have), then do not use a syntax that requires a copy operator.

Jim Dempsey

Blog: The Parallel Void

www.quickthreadprogramming.com
In cima
Ritratto di Raf Schietekat
Raf Schietekat
Ven, 07/12/2012 - 22:13

The problem with the proposed solution would be that parallel_for implies random iteration and parallel_for_each implies input iteration, which does not require the iterators' referents to persist beyond reference incrementation, so even without feeder functionality a copy is required to achieve parallelism. Perhaps template specialisation magic could save the day (tell me if I should have had a coffee first), but that can get complicated to implement and maintain and would muddle the situation, so why not instead make the intention clear by using parallel_for directly?

In cima

Accedere per lasciare un commento.