Quality RTOS & Embedded Software

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




Loading

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 ]    [ Sitemap ]    [ ]




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

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

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