Implementation of 'break' in parallel_for()

[quickwayne]

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

[robert-reed]

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.

[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

[ARCH_R_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.

[quickwayne]

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

[robert-reed]

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