Neil Thiessen

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

10 years, 1 month ago.  This question has been closed. Reason: Changed it to a discussion

RTOS Thread Variables Static vs. Local

I'm working on a multithreaded project using the mbed-rtos library, and I'm wondering whether it's preferable to keep the variables specific to each thread within the thread function itself, or make them "static". By "static", I mean put each thread in a separate file and declare its variables in an anonymous namespace so they're external to the thread function itself, but still somewhat concealed from the rest of the application.

As an example, one of the threads in my project, USB_Thread, communicates with a PC using the USBHID class in the USBDevice library. In addition to the USBHID object, it also uses a 1KB buffer to send and receive chunks of data. Which method of handling these variables is preferred?

Method A: "static" variables (default stack size)

namespace {
    USBHID hid(64, 64);
    char buffer[1024];
}
 
void USB_Thread(void const *args) {
    while (true) {
        //Do USB stuff!!!
    }
}

Method B: local variables (larger stack size)

void USB_Thread(void const *args) {
    USBHID hid(64, 64);
    char buffer[1024];

    while (true) {
        //Do USB stuff!!!
    }
}

It seems to me that keeping a thread's variables internal would make estimating your memory consumption easier, while also providing better encapsulation.

With internal, do you mean local? For a project of my own I went for exactly the opposite (at least for the buffers/larger stuff), for the same reason: It is a bit high on memory, and that way the compiler tells me how much RAM memory I am using with my buffers.

posted by Erik - 14 Mar 2014

Yes, local as in method B. Interesting... I would have thought estimating your memory usage would be easier with local variables since you can see what each thread will use simply by looking at the stack size you gave it when you created it... My other thought is that method B would make your threads more "portable", as in you could create additional instances without having to copy and paste static variables.

posted by Neil Thiessen 14 Mar 2014

From the code it might indeed be easier, then again estimating thread sizes is irritating imo :). It is true for portability it is better if your thread contains evertyhing.

posted by Erik - 14 Mar 2014

@Neil, what if you create a method C, allocate those objects within a thread on a heap?

posted by Martin Kojtal 15 Mar 2014

@Erik: Isn't it though? I hate estimating a stack size for threads! It would be nice if compilers were smart enough to analyze a thread's maximum stack depth based on every possible code path at compile time. Wishful thinking I know...

@Martin: Thanks, but I try to avoid using the heap on microcontrollers unless I absolutely have to. Besides, last I checked heap/stack collision detection was broken in the regular SDK let alone when the RTOS was used.

posted by Neil Thiessen 17 Mar 2014