ARM MicroLIB and malloc() thread safety with FreeRTOS

RE: ARM MicroLIB and malloc() thread safety with FreeRTOS

droberson — Thu, 03 Nov 2022 17:09:01 GMT

Ahhh, I overlooked that. Thanks for finding that! Makes sense. Other than increased RAM usage, are there any caveats or gotchas to not using MicroLIB? I notice that all the Nordic Keil uVision example projects use MicroLIB.

Edit: I found my answer: program hangs on startup if not using microlib and devzone.nordicsemi.com/.../rom-and-ram-management

I guess the only way to make malloc() thread safe with MicroLIB is to wrap it with a function that uses a mutex.

Thanks for your help!

Derek

RE: ARM MicroLIB and malloc() thread safety with FreeRTOS

Susheel Nuguru — Thu, 03 Nov 2022 08:28:29 GMT

Hmm, seems like microlib does not support mutex locks to guards agains the code that is not already thread safe.

Microlib does not provide mutex locks to guard against code that is not thread safe.

RE: ARM MicroLIB and malloc() thread safety with FreeRTOS

droberson — Wed, 02 Nov 2022 16:51:48 GMT

So this is what I have discovered after implementing the following functions as test code:

volatile SemaphoreHandle_t testMutex = (SemaphoreHandle_t) 0x00000012;

int _mutex_initialize(SemaphoreHandle_t *sid)
{
   *sid = testMutex;
   return 1;
   
   // /* Create a mutex semaphore */
   // *sid = CreateLock(...);
   // return 1;
}

void _mutex_acquire(SemaphoreHandle_t *sid)
{
   testMutex = * sid;
   
   /* Task sleep until get semaphore */
   //AcquireLock(*sid, ...);
}

void _mutex_release(SemaphoreHandle_t *sid)
{
   testMutex = * sid;
   
   /* Release the semaphore. */
   //ReleaseLock(*sid);
}

void _mutex_free(SemaphoreHandle_t *sid)
{
   testMutex = * sid;
   
   /* Free the semaphore. */
   //FreeLock(*sid, ...);
}

If I compile without MicroLIB (box not checked on Options for Target->Target), I see the following in the .map file:

"h1_free_mt.o(.text) refers (Weak) to main.o(i._mutex_acquire) for _mutex_acquire"

So I can see my implementation overriding the weak implementations. I can also see the code execute as shown below:

If I compile with MicroLIB and look at the .map file, there are no weak implementations of _mutex_acquire() and similar functions and thus nothing is overridden. Also, my breakpoint depicted above is never hit.

Question : Does this mean that MicroLIB doesn't use the _mutex_* functions? If not, then is malloc() thread safe in MicroLIB or is it inherently not thread safe with no way to make it thread safe?

Thanks,

Derek

RE: ARM MicroLIB and malloc() thread safety with FreeRTOS

droberson — Wed, 02 Nov 2022 16:02:14 GMT

Per Question 2 form above, do you have any ARM documentation that details the function prototypes and expected return values for the _mutex_* functions? I can't find anything.

Edit: I found this: https://developer.arm.com/documentation/dui0475/m/the-arm-c-and-c---libraries/multithreaded-support-in-arm-c-libraries/management-of-locks-in-multithreaded-applications?lang=en

I will try to implement per the spec above and report back after testing.

Thanks,

Derek

RE: ARM MicroLIB and malloc() thread safety with FreeRTOS

Susheel Nuguru — Wed, 02 Nov 2022 11:37:16 GMT

[quote user=""]Question 1: Is malloc(), free(), and realloc() thread safe in MicroLib? I am not sure whether the link above applies to the default C library or MicroLIB.[/quote]

I do not see that the weak implementation of _mutex_acquire , _mutex_free and _mutex_release has been patched with freertos mutexes. What I understand from the documentation of the arm c libraries is that there is a use of these weak implementation of mutexes inside these heap functions, but these are dummy functions not doing anything and expects to be overridden by the layer above. So what you need to do is that you need to overide the weak implementation of these C library functions with freertos mutexes API and the C library for these heap functions would make sure to call these overridden calls to ensure thread safety.

In short, you should override these functions using FreeRTOS API and the C library would take care of the rest to call them when needed.