Hi,
I'm running embOS 3.88c on a Cortex-M3 and I have a strange behavior in my application.
There are about 15 different tasks runing, and some of them do dynamic allocation using new, which calls malloc().
Sometimes, one of the tasks run at 100% and the debugger shows that the task is blocked in an infinite loop inside __malloc_internal.
The problem only occurs in real time execution, when debugging step by step, no infinite loop. This leads me to say it is multi task related.
So I'm wondering if the standard library is really thread safe : it is not, but can be with some hook functions. I found this in the EmbOs doc :
ARM says this :
Maybe someone already had this issue with new / malloc ?
Thanks
I'm running embOS 3.88c on a Cortex-M3 and I have a strange behavior in my application.
There are about 15 different tasks runing, and some of them do dynamic allocation using new, which calls malloc().
Sometimes, one of the tasks run at 100% and the debugger shows that the task is blocked in an infinite loop inside __malloc_internal.
The problem only occurs in real time execution, when debugging step by step, no infinite loop. This leads me to say it is multi task related.
So I'm wondering if the standard library is really thread safe : it is not, but can be with some hook functions. I found this in the EmbOs doc :
and indeed after some search in the source, I found the _mutex_* methods needed by the standard library to be thread safe.4.2 Thread-safe system libraries
The Keil MDK runtime libraries implement hook functions for thread safe usage of
system functions which are supported by embOS. Automatic thread safe locking
functions are always enabled. The embOS libraries compiled for and with the Keil
MDK compiler come with all code required to automatically handle the thread safe
system libraries.
ARM says this :
but there is no mention of __user_perthread_libspace() in the source code. Is this normal ? Should I implement my own to ensure thread safety ?To use the ARM C library in a multithreaded environment, you must provide:
An implementation of __user_perthread_libspace() that returns a different block of memory for each thread. This can be achieved by either:
returning a different address depending on the thread it is called from
having a single __user_perthread_libspace block at a fixed address and swapping its contents when switching threads.
You can use either approach to suit your environment.
You do not have to re-implement __user_perproc_libspace() unless there is a specific reason to do so. In the majority of cases, there is no requirement to re-implement this function [...]
Maybe someone already had this issue with new / malloc ?
Thanks