__start_other_cores thread

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
Active Member
Posts: 58
Joined: Tue Feb 13, 2018 2:50 pm

__start_other_cores thread

Postby MarcAntigny » Mon Jul 30, 2018 3:35 pm

Hi all,
I'm working with USB audio on Xcore 200 (XU232) and I got a troublesome thread in debug.
In a par statement, I launch two threads (task1 and task2). task1 will return a value (command) and tell task2 to end by returning 0 :

Code: Select all

unsigned foo(chanend c1, chanend c2)
	chan c_sync;
	unsigned command
            	command = task1(c1, c_sync);
             	task2(c2, c_sync);
    return command;
However when I ran my code in debug mode, the stack for task2 is :
tile[1] core[1] (Suspended)
4 __start_other_cores() 0x00043fba
3 foo() foo.xc:1009 0x0004253d
2 mainFoo() foo.xc:1302 0x00042d95
1 main() main.xc:275 0x00042e85
While for task1 everything seems OK
tile[1] core[2] (Suspended)
3 task1() foo.xc:599 0x000427cc
2 foo.task.0() foo.xc:1013 0x000427cc
1 __start_core() 0x000442b0
Has anybody an hint on this strange __start_other_cores thread ?
I guess this is a problem on task2 launch but I have no clue on how it appears (no unsafe pointers manipulation, no strange synchronization). I already clean-rebuild-unplug-relaunch xTimeComposer-etc... and I got the same problem.
Thanks a lot for your help.

XCore Addict
Posts: 169
Joined: Fri Oct 23, 2015 10:23 am

Postby robertxmos » Tue Aug 07, 2018 8:48 am

Hi Marc,

When you do a par, the parent core will first 'start other cores' for N-1 tasks and then pick up the last task and run it itself ... on its own stack.
The other tasks will each be given a new core and a new stack to run on.
The layout of where tasks are scheduled is deterministic as are the stacks - all statically calculated - but the exact order is not specified as canonicalisation rules are not specified!

I am not sure if I understand your stack trace as to where you think it should be re: is there a break point set in task2?
It looks like either:
1. task2 has completed and the parent is waiting for task1 to complete.
or more likely
2. the parent has not yet got around to starting task2 (off the top of my head I can't remember if all tasks are started at the same time... I don't see why they would be).

If you allow the code to run longer, I believe you will see task2's stack sat on top of the parent's stack.
Do let me know if this is not the case.


Who is online

Users browsing this forum: No registered users and 1 guest