Intel® oneAPI Threading Building Blocks
Ask questions and share information about adding parallelism to your applications when using this threading library.

Assertion ref_count race detected

Stefan_
Beginner
405 Views
Can somebody please help me? I'm getting this assertion:

Assertion !(prefix().extra_state & es_ref_count_active) failed on line 211 of file ../../src
/tbb/task.cpp
Detailed description: ref_count race detected


tbb40_20120613oss, boost_1_49_0, Visual Studio 2010, Windows 7 SP1, Core i7 860

[cpp]int main(int argc, char *argv[]) { tbb::parallel_for (0, 2000000000, [](int p_task_id) { if (p_task_id==0) { int sum = 0; boost::thread user_thread([∑] { for (int i=0; i<10000; ++i) for (int j=0; j<100000; ++j) sum += (i*j)%7; }); std::cout << sum; } else { if (p_task_id%1000000==0) std::cerr << "."; } }); }[/cpp]

EDIT:
I made sure that only one thread is created inside parallel_for. The same assertion still shows up.
EDIT:
sum is now declared inside user_thread. Still the same assertion.
EDIT:
undo my last change. I was wrong. moving sum into user_thread fixed the problem.
0 Kudos
1 Solution
Anton_M_Intel
Employee
405 Views
Another race seems on 'sum' because AFAIU user_thread is not a blocking call which creates thread and waits on it. So, the thread recieves reference to 'sum' and writes to it while the scope where it was defined is finished and the 'sum' is destroyed... which can easily lead to memory corruption in tbb task sceduler reporting the problem.

View solution in original post

0 Kudos
3 Replies
Vladimir_P_1234567890
405 Views
Hello, thanks for report.
I have a question: how many boost threads are created inside parallel_for? According to the code it should be 1-8 in random way sincefirst_task variable is shared and not guarded.
--Vladimir
0 Kudos
RafSchietekat
Valued Contributor III
405 Views
To get rid of the red herring (presumably), make first_task an atomic and use compare_and_swap().
0 Kudos
Anton_M_Intel
Employee
406 Views
Another race seems on 'sum' because AFAIU user_thread is not a blocking call which creates thread and waits on it. So, the thread recieves reference to 'sum' and writes to it while the scope where it was defined is finished and the 'sum' is destroyed... which can easily lead to memory corruption in tbb task sceduler reporting the problem.
0 Kudos
Reply