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.
11 years, 4 months ago.
Ram usage of Threads
Now a question from me :).
First of all, how much RAM does a thread use? Is it just the amount reserved in the Thread's constructor, or is that for variables, and is there more overhead?
Second, how do you find out the amount of RAM left in a thread? If you want to use a thread in an RTOS specific library, you don't want to have it using more than required. So easiest way would be measuring how much RAM is left, and then just lowering the amount of RAM reserved by that amount (well minus some safety margin). But I cannot seem to figure out how much is left. Malloc always seems to return a non-NULL pointer, even though there really is no space left. Also dynamic and static variables in a thread seem to be thrown on one heap, so I cannot look at the difference in their addresses.
2 Answers
11 years, 4 months ago.
Erik - wrote:
First of all, how much RAM does a thread use? Is it just the amount reserved in the Thread's constructor, or is that for variables, and is there more overhead?
172 bytes. 96 of these bytes are used for the _user_perthread_libspace.
Obviously, the biggest chunk of memory is the one allocated for the stack, by default: 2Kbytes.
Erik - wrote:
Second, how do you find out the amount of RAM left in a thread? If you want to use a thread in an RTOS specific library, you don't want to have it using more than required. So easiest way would be measuring how much RAM is left, and then just lowering the amount of RAM reserved by that amount (well minus some safety margin). But I cannot seem to figure out how much is left.
Yes, this is a very sensible question and the short answer is: we have an open ticket for it, we have still to implement this functionality.
A common way to implement it is to extent the typical stack overflow check: initialize each word of the stack to a given "magic number". When you want to know the maximum usage of the stack you simply start reading from the end of the stack until you find the first word that has been changed. This should give you a rough estimate of the amount of stack left in a thread.
Erik - wrote:
Malloc always seems to return a non-NULL pointer, even though there really is no space left.
I found this topic: http://mbed.org/forum/mbed/topic/3803/, where it seems they disabled the heap/stack collision detection, and I think that prevents malloc from returning zero.
Yes, exactly. The ARM C standard library heap/stack collision detection is broken in a multi threads environment, therefore we had to disable it.
Unfortunately, it is not really possible to override a small part of it to tailor the collision detection to our use case, we will have to rewrite a large chunk of the memory allocator and of the collision detection.
We have not really started doing this work, because it would not be scalable for our current approach of supporting multiple toolchains: we cannot duplicate this effort for each standard library of each toolchain.
We are considering adopting a single C standard library to be recompiled for each of the supported toolchains, the most likely candidate at the moment is "newlib-nano".
If we adopt a single C standard library we could work much more in depth with its customization.
Cheers, Emilio
Thanks for the indepth answer :).
I guess as you say by initializing the stack manually with a certain value it should be fairly easy to figure out the amount of RAM left. If you manually supply the char array for the stack you even know the used address space, so it should actually be straigtforward for a library to check if newly initialized variables are still inside the thread's stack (preferably before they overwrite any other data).
posted by 02 Jul 2013
11 years, 4 months ago.
I'm surprised that malloc always returns non-zero. In fact one of the published functions to estimate the amount of free heap uses that property of malloc to find the largest block that can be allocated. That was however before RTOS. Maybe the RTOS has its own memory allocator that works in a non-standard way.
I found this topic: http://mbed.org/forum/mbed/topic/3803/, where it seems they disabled the heap/stack collision detection, and I think that prevents malloc from returning zero.
posted by 01 Jul 2013