__TBB_ASSERT( my_global_top_priority >= a.my_top_priority, NULL );

[MLema2]

__TBB_ASSERT( my_global_top_priority >= a.my_top_priority, NULL );

I get this assert when doing a parallel_for:

tbb::task_group_context context(tbb::task_group_context::isolated);

context.set_priority(tbb::priority_high);

tbb::parallel_for(range, functor, tbb::auto_partitioner(), context);

Values of local variables:

my_global_top_priority = 1

a.my_top_priority = 2

We have multiple normal threads that might do parallel tasks with either normal or high priority.

Usually, high priority tasks occurs from threads with higher priority. and are meant for fast user input responses.

Call stack looks something like this:

tbb_debug.dll!tbb::assertion_failure

tbb_debug.dll!tbb::internal::market::lower_arena_priority(tbb::internal::arena & a={...}, __int64 new_priority=1, __int64 old_priority=2) Line 459 C++

tbb_debug.dll!tbb::internal::arena::is_out_of_work()

tbb_debug.dll!tbb::internal::custom_scheduler<:INTERNAL::INTELSCHEDULERTRAITS>::receive_or_steal_task(__int64 & completion_ref_count=2, bool return_if_no_work=false) Line 302 + 0x11 bytes C++

tbb_debug.dll!tbb::internal::custom_scheduler<:INTERNAL::INTELSCHEDULERTRAITS>::local_wait_for_all(tbb::task & parent={...}, tbb::task * child=0x0000000002156740) Line 548 + 0x69 bytes C++

tbb_debug.dll!tbb::internal::generic_scheduler::local_spawn_root_and_wait(tbb::task & first={...}, tbb::task * & next=0x0000000002159bc0) Line 629 + 0x35 bytes C++

tbb_debug.dll!tbb::internal::generic_scheduler::spawn_root_and_wait(tbb::task & first={...}, tbb::task * & next=0x0000000002159bc0) Line 536 C++

OurLib.dll!tbb::task::spawn_root_and_wait(tbb::task & root={...}) Line 693 C++

OurLib.dll!tbb::interface6::internal::start_for<...>::run

OurLib.dll!tbb::parallel_for

[MLema2]

BTW, ignoring the assert seems to be fine..

[SergeyKostrov]

Quoting mlemay@coveo.com

...I get this assert when doing a parallel_for:

tbb::task_group_context context(tbb::task_group_context::isolated);

context.set_priority(tbb::priority_high);

tbb::parallel_for(range, functor, tbb::auto_partitioner(), context);
...

Did you have any problems after that? Also, did you try to execute a Release version of your application?

Asserts are displayed in Debug configurations only and sometimesthey are simplywarning a Software Developer that something is possibly wrong.

[Anton_M_Intel]

Hi, thank you for the report.

Do you use the most recent version of TBB? Update 2 contains some fixes in the scheduler'sis_out_of_work().

If yes: it supposes we have a race in task priorities implementation which may cause your priority setting to be [temporarly] ignored. Could you please cut a reproducer out from your code and submit it to us? It will greatly help the investigation.

[MLema2]

We use TBB 4.0 U2 (tbb40_278oss).

Is there any fixes between theses two updates that could resolve this?

I only got this assertion once while doing heavy stress tests of our applications. I'm not sure I can easily reproduce it. I will do my best to come up with a sample application that raise this assertions.

Meanwhile, if this happens again, that assertion means nothing more than a warning about some temporarily valid but wrong state?