Hi Steven,

Great answer, I'm sure many users will benefit from your well written detailed explanation.

Charles

+1 Steven

Hi Steven, first of all, thank you for your very detailed answer, which I think many users out there will benefit from. It is very comprehensive, but doesn't directly answer my question.

Part of the problem for me is that I come from the Windows programming world, specifically .NET, and I didn't know what to expect when I started using threads with mbed. For example, if I were to spawn multiple threads and my application exited, those threads would continue to run and my application would remain executing (as shown in the Task Manager).

I think the first two sentences are the ones I'd like to focus on, because they are what's super relevant to my question. What I'm hearing is that when a thread "object" is created (which starts it as well), the responsibility for its execution isn't just handed over to a thread scheduler, and under the hood there are things happening that allow the thread to execute "simultaneously" with other threads. This partially explains why a thread that has been created on the heap gets terminated when the function that it is created in exits. Note that I'm not talking about the entry function here.

For example, if I had something like this:

void thread1_func(void const *args) { while(1) { B1(); Thread::wait(100); } }

void foo(void) { Thread *thread = new Thread(thread1_func); do something here, then exit }

void main(void) { foo(); while(1) { Thread::wait(100); } }

From what I have experimented with, I believe the thread will get terminated. I suppose that I will have to dig into the code to understand what causes that, though I was hoping for a higher level view of what is going on here.

That's why I'd like to find some kind of "best practices" post - something that says (for example), "always create threads in main() and pass a structure to each one that it specifically needs to interact with", or "if you create a thread in a function, never let that function exit". I have already established that the second case is necessary for the thread to continue to function.

Hi Dave,

It sounds like you're familiar with general thread behaviour (and all of its "interesting" quirks) :-)

I guess the real question is what happens to the underlying "executing thread" when its respective "thread object" goes out of scope (and/or is deconstructed) - does the executing thread get terminated or does it keep running?

I'll try some experiments myself tonight if I get a chance.

Hi Steven, yes, the thread object itself doesn't get destroyed, because I can query its State via get_state() in my main function. In other words, my main() calls a function that creates a thread object, then returns a pointer to the thread object (this was not part of the original design, but merely a way to try to understand what is going on), and the pointer is still valid when the function returns. The State of the thread starts as 1, then 8 before the function exits, and when it exits, the State becomes 0, which is terminated.

I thought that perhaps the stack might have something to do with it, but my experiments proved otherwise.

Thank you so much for bouncing ideas around with me!

Hi Dave,

Here are my findings so far....

#include "mbed.h"
#include "rtos.h"



DigitalOut led1(LED1);
DigitalOut led2(LED2);
 
void led2_thread(void const *args) 
{
    while (true) 
    {
        
        led2 = !led2;
        Thread::wait(1000);
    }
}
 
int main() 
{
    Thread thread(led2_thread);
    
    while (true) 
    {
        led1 = !led1;
        Thread::wait(500);
    }
}

This is taken from mbed RTOS handbook page (https://mbed.org/handbook/RTOS). In this case, main never exits, the thread object is on the stack and is kept in scope, and the thread function never exits. As expected, the thread continues to run.

#include "mbed.h"
#include "rtos.h"



DigitalOut led1(LED1);
DigitalOut led2(LED2);
 
void led2_thread(void const *args) 
{
    while (true) 
    {
        
        led2 = !led2;
        Thread::wait(1000);
    }
}
 
int main() 
{
    Thread* pThread = new Thread(led2_thread);
    
    while (true) 
    {
        led1 = !led1;
        Thread::wait(500);
    }
}

Same as thread test 1, only this time, the thread object is allocated on the heap. Thread runs OK.

#include "mbed.h"
#include "rtos.h"



DigitalOut led1(LED1);
DigitalOut led2(LED2);
 
void led2_thread(void const *args) 
{
    while (true) 
    {
        
        led2 = !led2;
        Thread::wait(1000);
    }
}
 
 
void StartTheThread(void)
{
    Thread thread(led2_thread); 
    
    Thread::wait(5000); //give the thread a chance to run
     
}
 
int main() 
{
    StartTheThread();
    
    
    while (true) 
    {
        led1 = !led1;
        Thread::wait(500);
    }
}

This time the thread object is created on the stack within the *StartTheThread* function. This function is called in the context of the main thread which sleeps for 5 seconds after it creates the test thread. The test thread starts and runs for 5 seconds. Once the 5 seconds is up, the StartTheThread function exits, causing the thread object to go out of scope and therefore be deconstructed. This had the effect of stopping the execution of the test thread. This implies that the thread object must remain in existence for the thread to continue running

#include "mbed.h"
#include "rtos.h"



DigitalOut led1(LED1);
DigitalOut led2(LED2);
 
void led2_thread(void const *args) 
{
    while (true) 
    {
        
        led2 = !led2;
        Thread::wait(1000);
    }
}
 
 
void StartTheThread(void)
{
    Thread* pThread = new Thread(led2_thread); 
    
    Thread::wait(5000); //give the thread a chance to run
     
}
 
int main() 
{
    StartTheThread();
    
    
    while (true) 
    {
        led1 = !led1;
        Thread::wait(500);
    }
}

Same as test 3, but this time the thread object is allocated on the heap. The thread starts running as before, and continues to run after the 5 second timer expires.

#include "mbed.h"
#include "rtos.h"



DigitalOut led1(LED1);
DigitalOut led2(LED2);
 
void led2_thread(void const *args) 
{
    while (true) 
    {
        
        led2 = !led2;
        Thread::wait(1000);
    }
}
 
 

 
int main() 
{
    
    Thread thread(led2_thread);
    
    
    for(int i=0; i<10; i++)
    {
        led1 = !led1;
        Thread::wait(500);
        
        
    }
}

In the above case, the thread object is created on stack, but this time, main no longer has a forever loop. Instead it will exit after 5 seconds (10 iterations, each with a 500ms delay). This time, the thread started as before, but when main exited (and the thread object went out of scope), the thread stopped executing.

#include "mbed.h"
#include "rtos.h"



DigitalOut led1(LED1);
DigitalOut led2(LED2);
 
void led2_thread(void const *args) 
{
    while (true) 
    {
        
        led2 = !led2;
        Thread::wait(1000);
    }
}
 
 

 
int main() 
{
    
    Thread* pThread = new Thread(led2_thread);
    
    
    for(int i=0; i<10; i++)
    {
        led1 = !led1;
        Thread::wait(500);
        
        
    }
}

Same as test 5, but this time the thread object is created on the heap. As before the thread starts running, but this time when main exits, the thread continues to run.

Perhaps you could give these examples a go and see if you get the same results?

Hi Steven, thanks for posting that. Before I posted my original question, I had performed those same tests. 1, 2, 3 and 5 were almost exactly the same and I had the same results. However, 4 and 6 I did *not* wait for 5 seconds. My original intent was to have a while loop that checks get_state() and waits until the thread was in the running state, but I think I shifted direction at some point and ended up letting the function exit. It could be that a thread remaining in memory really is all that's necessary, as I had originally expected, *except* that I additionally need to wait for the thread to start running! I'll give this a go. Thanks a bunch!

Steven, I think we're on the right track - it sure seems like just waiting 5sec after creating the thread makes everything work, so perhaps the thread only terminates when the function exits *if* it isn't yet in a running state. I think the right thing to do now is to figure out when is the right time to leave the function w/o sleeping for an arbitrary period of time.

I alluded to this in the first comment to my original post, which was stating that I was having trouble figuring out what value to test against get_state().

Here's the updated code I am currently using - rather than wait a fixed amount of time, I'm waiting for the thread to enter the WaitingMailbox state.

    Thread *thread = new Thread(ServerThread, (void *)&_package);
    while( thread->get_state() != rtos::Thread::WaitingMailbox) {
        Thread::wait( 100);
    }

Unfortunately, I cannot find any information about WaitingMailbox, or why I should be looking for that state before exiting my function... I'm basing that off of observation in the case that the thread is running properly and get_state() returns 8. :) Can you point me in the right direction?

Steven, how did you get the code block in the comment?

Are you making some kind of blocking call inside your thread function (e.g. reading from a socket)?

To put code inside code tags use << code>> some code << /code>>...just remove the space after the <<

I'm just doing a Thread::wait(20). I would have guessed that would correspond to WaitingDelay or WaitingInterval, but not WaitingMailbox. In uCOS, I vaguely recall using mailboxes for something totally different, like interprocess comms, so it doesn't seem applicable in my scenario.