Thursday, May 24th 2018, 4:14am UTC+2

You are not logged in.

  • Login
  • Register

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.



Date of registration: Mar 11th 2014

Posts: 3


Tuesday, September 23rd 2014, 10:35am

EmbOs and C/C++ STL multitask safety


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 :


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.
and indeed after some search in the source, I found the _mutex_* methods needed by the standard library to be thread safe.

ARM says this :


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 [...]
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 ?
Maybe someone already had this issue with new / malloc ?



Super Moderator

Date of registration: Nov 14th 2007

Posts: 271


Tuesday, September 23rd 2014, 2:19pm

Hello Marc,

if you have a valid support and update agreement (and I think you have) you can contact our support directly per email.
You can find the according email address in the embOS generic documentation.
That makes it easier for us to give you best support.

There are hook functions for thread safety and for thread local storage.
We already support the thread safety functions (_mutex_* ) and I will check if we have to implement the thread local storage functions too (I think so).

Best regards,



Date of registration: Mar 11th 2014

Posts: 3


Tuesday, September 23rd 2014, 4:33pm

Thanks for your answer,
I received your mail, I will continue with the support then.

Similar threads