Quality RTOS & Embedded Software

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




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) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists