Current state of thread safety with FreeRTOS and standard libraries?

[scottm]

This thread from a year and a half ago discusses the problems with non-thread safe library functions in the FreeRTOS demos.

With FreeRTOS being NXP's preferred RTOS now, has anything been done since then to improve the situation?  Redlib is the default and other posts have discussed how Redlib isn't thread-safe and that there were no plans to make it so due to lack of demand.

Does NXP recommend using Newlib with FreeRTOS?  Are there specific instructions?

Scott

[danielchen]

Hi Scott:

Here is a document explaining the differences:

What are Redlib and Newlib? 

For how to switch the libraries, please refer to

https://community.nxp.com/thread/389104 

My recommendation:  if you want thread safe, please use Newlib

Regards

Daniel

[scottm]

Hi Daniel,

I'm bumping this old thread because I'm still spinning my wheels trying to find a proper solution.  Correct me if I'm wrong, but NXP's recommended C runtime library is Redlib and recommended RTOS is FreeRTOS, but as you've previously stated Redlib is not thread safe.  Nevertheless, the default setup for NXP's own RTOS demo applications I've checked uses Redlib.

In accordance with your recommendation, I switched to Newlib.  The problem I'm having now is that Newlib allocates memory on the heap as needed for stdio streams, and that memory is not freed when the task is deleted.  This leads to a sizable memory leak if any task is periodically started and ended.

I'm sure there's a solution, but what gets me is that I'm not trying to do anything exotic here.  I just want a supported RTOS + runtime library configuration that is thread safe and doesn't leak memory.  How do you suggest I do that?  Can you point to any example application that you're reasonably confident is correct and safe?

Thanks,

Scott

[danielchen]

Hi Scott:

Yes, the default runtime library is Redlib.

For Newlib, there is an issue with FreeRTOS demo as described in Dave's post.

We fixed this and this will be released in next SDK release, maybe the beginning of 2019.

But your issue now is the memory not freed when the task is deleted, it is a different issue.  The memory is freed by the idle task, that is stated in below link.

http://www.freertos.org/a00126.html

The idle task is responsible for freeing the RTOS kernel allocated memory from tasks that have been deleted. It is therefore important that the idle task is not starved of microcontroller processing time if your application makes any calls to vTaskDelete (). Memory allocated by the task code is not automatically freed, and should be freed before the task is deleted.

Regards

Daniel

[scottm]

But your issue now is the memory not freed when the task is deleted, it is a different issue.  The memory is freed by the idle task, that is stated in below link.

That's not the issue here.  The issue is that, at least with _REENT_SMALL, the first call to a buffered I/O function will create file pointers for the stdio streams.  FreeRTOS does call _reclaim_reent() when the task is deleted, but Newlib apparently doesn't free the stdio file pointers.  Because the memory is not allocated as part of the TCB, FreeRTOS doesn't know about it and can't free it directly.  I'm working that issue on the FreeRTOS forum.

Yes, the default runtime library is Redlib.

Here's what MCUX support said about Redlib:

Redlib was always designed as a simple, Embedded C library. And at present we have no plans to make it thread safe - we have seen little or no demand for this (in the 10 years or so that we have been supplying Redlib). 

So Redlib is not thread safe but it's the default and the one recommended for use with FreeRTOS by NXP.  What's the reasoning here?  Does NXP consider the danger to be overstated?  Does NXP assume that everyone knows that Redlib isn't thread safe and knows how to make it safe?

I had a product launch delayed by more than two months because of a race condition that turned out to be caused by a bug in the FreeRTOS kernel.  It's incredibly frustrating trying to track down a crash that might not happen for days, and these devices need to be able to operate for years without maintenance, and some are installed in extremely remote locations.  Knowing that my standard libraries are safe to use is not just an academic concern.

Thanks,

Scott