Implementation of 'break' in parallel_for()

Implementation of 'break' in parallel_for()

Portrait de quickwayne@gmail.com

Hello,

There is a 'break' in my for loop so that in case it finds out the result, it quits the loop. When I apply parallel_for() on the loop, the 'break' in operator() can only terminate current task. However, tasks mapped to other thread or tasks not mapped yet will keep running. I am wondering if I can kill these tasks if break condition meet. Thanks a lot.

Greetings, Sunwei

6 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.
Portrait de robert-reed (Intel)

Do you know about the previous discussion about break in parallel_for held in this forum? It gives a pretty good idea how to do it. If you've got some added wrinkle or other concern after reading that, carry on with this thread and I'm sure you'll get an answer.

Portrait de jimdempseyatthecove

Sunwei,


Consider adding a volatile bool done flag to indicate solution found (or error). The other threads can test for done/error and bail out.


Jim Dempsey


www.quickthreadprogramming.com
Portrait de Arch D. Robison (Intel)

My blog http://softwareblogs.intel.com/2007/11/08/have-a-fish-how-break-from-a-parallel-loop-in-tbb/explains a solution that keep most of the unmapped tasks from being created at all once a parallel loop is cancelled.

Portrait de quickwayne@gmail.com

Hello, rread, Jim, adiobiso,

Thanks for your reply. It works now. Meanwhile sorry for not reading previous message before posting.

adiobiso,
Your blog is very good. It's also good example to show how to extend TBB. I enjoy both the fish and fishing. :) Meanwhile I don't fully understand the description of "thrashing". If "stop" is on a cache line written frequently, it makes "stop" hot in cache and sounds better. Thanks.

--Sunwei


Portrait de robert-reed (Intel)

In the code Arch shared, my_stop is declared volatile and passed by reference to every parallel loop body that uses that cancelable_range. That means every call to r.end() does a read request on the cache line containing my_stop. This is not a problem if no thread is writing to that cache line in the course of the loop. Each HW thread would get a private, read-access copy of the cache line and proceed without thrashing until loop termination or until some thread writes my_stop, all the other copies get invalidated and the new cache line gets propagated.


If some thread was regularly writing to that cache line, all other threads' copies would be invalidated regularly, forcing extra bus activity to reread the line even though the value of my_stop has not changed. This syndrome of unnecessary evictions because of cache line coincidenceis known as false sharing.


--Robert

Connectez-vous pour laisser un commentaire.