Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

Terminating problem from parallel_reduce

nuntawat
Beginner
79 Views

See code snipet below:

[cpp]for(list::iterator iter = (*block_list).begin(); iter != (*block_list).end(); iter++)
{
  // Do someing
}[/cpp]

When for loop iterate all member inside block_list variable, ideally, it should be stopped and exited, but I found that the new thread has come and start iteration again! How do I terminate all threads when it ends iteration? Thanks very much.

0 Kudos
3 Replies
robert-reed
Valued Contributor II
79 Views
Quoting - nuntawat

See code snipet below:

[cpp]for(list::iterator iter = (*block_list).begin(); iter != (*block_list).end(); iter++)
{
  // Do someing
}[/cpp]

When for loop iterate all member inside block_list variable, ideally, it should be stopped and exited, but I found that the new thread has come and start iteration again! How do I terminate all threads when it ends iteration? Thanks very much.

I fear there's just not enough context here to make much of a guess about what may be going on with your code. Could you provide more of the details, showing at least how you engaged your iterator in the context of a parallel_reduce call?
nuntawat
Beginner
79 Views
I fear there's just not enough context here to make much of a guess about what may be going on with your code. Could you provide more of the details, showing at least how you engaged your iterator in the context of a parallel_reduce call?

There is a lot of codes, but I captured only codes used to determine condition and iterate loop inside.
[cpp]
public:
static currentMutex_t mutex;
static point_t current_point;



void operator() (const blocked_range& range) const { // Begin Queuing Mutex Lock currentMutex_t::scoped_lock lock(mutex, false); int block_num = 0; for(list::iterator iter = (*block_list).begin(); iter != (*block_list).end(); iter++) { local_work(*iter, &block_num, lock); } } void local_work(unsigned char **xc, int *block_num, currentMutex_t::scoped_lock &lock) const { int tmp_x_pos, tmp_y_pos; tmp_x_pos = current_point.x_pos; tmp_y_pos = current_point.y_pos;
for(int i = tmp_y_pos; i < tmp_y_pos + pixel_per_block; i++) { for(int j = tmp_x_pos; j < tmp_x_pos + pixel_per_block; j++) {
// Do sometasks... } }


if((current_point.x_pos + pixel_per_block) < ncols) { if(((current_point.y_pos + pixel_per_block) <= nrows) || (current_point.y_pos == nrows)) { lock.scoped_lock::upgrade_to_writer();
current_point.x_pos += pixel_per_block; current_point.y_pos -= pixel_per_block;
lock.downgrade_to_reader(); } } else if (current_point.y_pos != nrows) { lock.scoped_lock::upgrade_to_writer(); current_point.x_pos = 0; (*block_num)++; lock.downgrade_to_reader(); } }
[/cpp]
RafSchietekat
Black Belt
79 Views
I have only briefly glanced at the code, but it seems highly problematic that you want to use blocked_range without actually using the parameter range. That's after I never understood what a linear list was doing here, and I still don't see it. Plus there's the current_point navigation: are you certain this wouldn't work better with blocked_range2d on the pixels?
Reply