Porting TBB to VxWorks, test_task unit test hangs

[lofwyr]

I am currently trying to port Threading Building Blocks Version 4.0 Update 3to VxWorks 6.9.1 using the GNU toolchain (gcc version 4.3.3)for a Sandybridge target. At this point I am able to build libtbb_debug.so and libtbbmalloc_debug.so, as well as most of the unit test suite.

I have successfully ran the following unit tests consistently with passing results:

test_assembly.vxe
test_atomic.vxe
test_yield.vxe 4:8
test_handle_perror.vxe
test_task_auto_init.vxe
test_task_scheduler_init.vxe 1:4
test_task_scheduler_observer.vxe 1:4

However, when I run test_task.vxe 1:4, the test alwayshangs in the call to TestDispatchLoopResponsiveness in TestMain, specifically in the first call tot.SpawnAndWaitOnParent(). From some cursory debugging, the execute method in the TaskWithChildToSteal object is never getting called by the scheduler, so the main thread just spins waiting on this.

I tried stepping through the parent()->spawn(*this) call, but I don't understand the scheduling code enough to understand what isactuallyhappening.

It seems like this is a simple test case, so the issueis probably fundamental. Any ideas on what could be the issue?

Thanks in advance.

[Vladimir_P_1234567890]

Hello,

could you put backtrace here pls?

Thanks,

Vladimir

[lofwyr]

Here is my gdb session output after the main thread (iTest_task)has hit abreakpoint at line 618 in test_task.cpp and I have manually paused the new thread that has been just been spawned (pthr1):

(gdb) info threads

No selectable - title : List of Tasks for RTP 23

* 24 0x818C010 iTest_task Stop 0x40C10CB6 TaskWithChildToSteal::SpawnAndWaitOnParent (this=0x3A005C20) at test_task.cpp:618

28 0x8186770 pthr1 Stop 0x40C5E5C4 tbb::internal::custom_scheduler<:INTERNAL::INTELSCHEDULER>

Traits>::receive_or_steal_task (this=0x3A005F80, completion_ref_count=@0x3A006410) at custom_scheduler.h:273

(gdb) bt

#0 TaskWithChildToSteal::SpawnAndWaitOnParent (this=0x3A005C20) at test_task.cpp:618

#1 0x40C0D152 in TestDispatchLoopResponsiveness () at test_task.cpp:635

#2 0x40C0EB08 in TestMain () at test_task.cpp:789

#3 0x40C0EBC6 in main (argc=,argv=) at harness.h:270

#4 0x40C07501 in _start () at _start+0x50

#5 0x0057C6A0 in UserReturn () at UserReturn

(gdb) thread 28

[Switching to thread 28 (parent process 23)]

28 0x40C5E5C4 tbb::internal::custom_scheduler<:INTERNAL::INTELSCHEDULERTRAITS>::receive_or_steal_task (this=0x3A005F80, completion_ref_count=@0x3A006410) at C:/TBB/src/tbb/custom_scheduler.h:273

(gdb) bt

#0 tbb::internal::custom_scheduler<:INTERNAL::INTELSCHEDULERTRAITS>::receive_or_steal_task (this=0x3A005F80,completion_ref_count=@0x3A006410) at custom_scheduler.h:273

#1 0x40C564EC in tbb::internal::arena::process (this=0x3A003C80,s=@0x3A005F80) at arena.cpp:93

#2 0x40C53F35 in tbb::internal::market::process (this=0x3A004A00,j=@0x3A005F84) at market.cpp:393

#3 0x40C4F0D6 in tbb::internal::rml::private_worker::run (this=0x3A003A80) at private_server.cpp:263

#4 0x40C4F211 in tbb::internal::rml::private_worker::thread_routine (arg=0x3A003A80) at private_server.cpp:231

#5 0x40CBD51C in ()

#6 0x40CCE3EA in ()

#7 0x40CCE3EA in ()

Sounfortunately the entire backtrace isn't availabe for pthr1, but I can tell you that it is simply spinning in the function: tbb::internal::custom_scheduler<:INTERNAL::INTELSCHEDULERTRAITS>::receive_or_steal_task. Meanwhile threadiTest_task spins infunction TaskWithChildToSteal::SpawnAndWaitOnParent (lines, 618,619).

It's also worth noting that I had a breakpoint set on the first line of TaskWithChildToSteal::execute from the beginning and it was never hit.

[Vladimir_P_1234567890]

Thanks, I hope this would be enough to diagnoze the problem

--Vladimir

[Anton_M_Intel]

Unfortunately, I cannot say something particular from this call stack because it is rather a consequence of already happened miscommunication between threads. Somehow the spawned task is not visible for the receive_or_steal method. Please check that a correct include/tbb/machine layer is included and defines all the necessary instruments with all the necessary intrinsics, assembler code, correct memory fences... etc