Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


Is it safe to use the standard malloc() with heap_1.c ?

Posted by shubham294 on August 9, 2017

Hi folks,

I was wondering if it is safe to use the standard malloc and memcpy (for non-FreeRTOS related things) in my FreeRTOS application along with static heap implementation (heap_1.c). If no, which implementation would you suggest? I am aware that it isn't the best practice but I am wonderring if it is safe to use if really needed.

My target is TI's AM3358 on Beaglebone Black running FreeRTOS v9.0.

I am using this port for AM335x. Kudos to this gentleman!

Is it safe to use the standard malloc() with heap_1.c ?

Posted by richard_damon on August 9, 2017

Malloc starts off non-thread safe, as it uses some internal state to keep the state of the heap. The simplest solution if you need dynamic allocations and deallocations is to just use a higher number heap version that supports what you need and use that yourself. The only issue is if you use any library functions that call malloc itself, then you need to do something more complicated.

The next step up is to define your own malloc/free that call pvPortMalloc / vPortFree to be thread safe, which works as long as nobody is calling the other heap functions, particularly realloc(), since FreeRTOS doesn't have a threadsafe version of these.

Another step would be to wrap all cals to any function that might use the heap with some from of protection (like stoping and starting the scheduler), but this is the risk that you might miss one (which would lead to possible heap corruption if two threads are in the heap functions at once),

Some libraries, if they were anticipating being used in a multi-thread enviroment will have a call back function to allow you to make the library thread-safe. (they can't provide it themselves, as they don't know what os you are using). One common example is newlib/newlib-nano which is somewhat common, can be configured to have such a call back. If the standard library you are using has such a feature, defining that call back is the best solution.

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS v10.2.1 is available for immediate download. MIT licensed, includes 64-bit RISC-V, NXP Cortex-M33 demo & Nuvoton Cortex-M23 demo.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers





STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner