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:
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.
(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
#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=
#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
#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.