threadx icon indicating copy to clipboard operation
threadx copied to clipboard

Newlib + threadx

Open Mula-Gabriel opened this issue 9 months ago • 19 comments

I use ThreadX with Newlib (or Newlib-nano) on several NXP microcontrollers. I'm using the version of Newlib provided by NXP with MCUXpresso (Newlib version 4.3.0, Mcuxpresso 24.12 ). Newlib is built with multithreading support enabled (SINGLE_THREAD is not defined) and with _RETARGETABLE_LOCKING enabled.

I’ve implemented all the _retarget_lock***** functions using ThreadX mutexes, and I’ve made sure in the linker script that the Newlib-managed heap doesn’t overlap with any byte pool or extended objects managed by ThreadX. I chose this approach because it felt more "complete" than implementing only the specific lock hooks like __malloc_lock or __env_lock. With this setup, I can use malloc or printf from multiple threads, and everything seems stable.

However, after reading this section on reentrancy, I’m concerned that I may not be managing __reent properly.

Option 1: Manually managing the struct _reent per thread seems error-prone to me. Ideally, I’d like this structure to be handled automatically.

On FreeRTOS, there’s a compilation flag configUSE_NEWLIB_REENTRANT that updates _impure_ptr during vTaskSwitchContext.

Question: On ThreadX, what are the recommended practices to properly manage the _reent struct?

Mula-Gabriel avatar Apr 12 '25 16:04 Mula-Gabriel