This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1310: Creating tasks within other tasks

Part Number: CC1310

Hi,

I'm pretty new to RTOS programming and was given a project where some work was already done (also by someone with limited RTOS experience). It's mostly code compiled from various different SDK examples. It is all working at the moment so this is not the problem. I just have some general question about thread/task creation where I couldn't find the answer in the documentation. 

Our current setup is something like this: 

int main() 
{
    pthread_create( ..., *thread_A, ...);  // created in detached state
    BIOS_start();
}

void *thread_A()
{
    GPIO_init();
    ...

    pthread_create( ..., *thread_B, ...);  // created in detached state
    pthread_create( ..., *thread_C, ...);  // created in detached state
    
}

First of all, I'm not sure where this "thread within thread" structure came from. Is this the way to do it or is this wrong and it just didn't break yet? A colleague thought this had something to do with setting up the kernel and idle tasks and all other threads should be created within Thread_A. Also does the same apply when switching from pthreads to tasks? Can you create tasks from within other tasks or does this mess up scheduling and debugging (i.e. execution analysis)? 

Our tasks basically run forever. At startup it is determined in what mode the system is running and which tasks need to be executed. Can you "bundle" tasks in another task and start this one task depending on the state (similar to the code above)? Or do you start tasks hierarchically "flat" (from the main) and decide for each task if it needs to be started or not? 

Sorry for the many questions, but I couldn't find an answer in the documentation or the forum. 

Thanks and greetings,

Max

  • Hi Max, 

    Thank you for the question!

    Task creation within a task should not generally be a problem. And in your case where the tasks run forever, it doesn't seem like it creates any issue.

    But when you talk about bundling tasks, do you need concurrency with multi tasking in your case? Or is it fine to do the actual work of the tasks in the parent task itself? 

    Here is a thread which maybe interesting to you. It also quotes another thread regarding task switching. 

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/545482/creating-new-tasks-within-a-task

    Regards,

    Sid

  • Hi Sid,

    alright, thanks for the info. 

    We have different modes (i.e. debugging, calibration, application, power save etc.) and depending on the mode, certain sensor readout threads need to be started (or not). I kind of forgot that you could just "bundle" them in a regular function call to start the threads.  

    Will try it out and play around a bit and see what happens. 

    Would you need to allocate enough stack space for Task_B and Task_C (as in the example above) in the Task_A stack? Or do they get allocated "flat" i.e. not in the Task_A stack? 

    Greetings,

    Max

  • Hi Max, 

    It should not be necessary. The task should be large enough to handle the context saving required when there is an interrupt. Also, it should be large enough to handle all the function calls in the task function. But once you spawn another task with its own stack, it should be able to handle the context switching on its own, independently. 

    A quick test with minimal code and a parent with a smaller task size than the child task could be useful. 

    Regards,

    Sid