Memory allocations for task in RTOS

Thread Starter

Pushkar1

Joined Apr 5, 2021
401
Memory in an MCU consists of Registers, RAM and ROM (flash). Variable data is stored in RAM. Heap and stack are allocated from RAM. Memory space is wasted only if we are permanently occupying space that can be used somewhere else. We use dynamic allocation only if we intend to release the space after the function has been executed, why heap memory is used for for FreeRTOS Task's?
 

Papabravo

Joined Feb 24, 2006
17,228
There is no "one size fits all" answer. The heap and the stack are created and initialized after all of the of the "fixed" allocations have been taken care of. This means that for the sake of efficiency the OS may allocate at the time it is built certain fixed areas of RAM designed for rapid access precisely because they don't need to be dynamically allocated and released. The OS designer can do this because he knows how much of the RAM resource to reserve for this purpose. Like many other things this is a choice that may or may not show up in a given OS.

It is a grave mistake to assume that all OS's are implemented in exactly the same way. There will be similarities to be sure, but there will also be critical differences. Instead of asking generic questions dig into your free RTOS and determine what choices they made and ask why they made those choices. The more more precise your questions the more useful the answers will be.

I should point out that choosing to support a heap has major performance implications because it usually takes considerable time to allocate and free chunks of memory and after a while memory becomes fragmented and you have to bring everything to a grinding halt while you do the "garbage collection" function. Great care must be exercised in performing this function because any mistake will be likely to cause a system crash. This was true in the era of limited memory. In todays systems the available memory could potentially be so large as to not have the same restrictions.
 
Last edited:

Thread Starter

Pushkar1

Joined Apr 5, 2021
401
I should point out that choosing to support a heap has major performance implications because it usually takes considerable time to allocate and free chunks of memory and after a while memory becomes fragmented and you have to bring everything to a grinding halt while you do the "garbage collection" function.
Dynamic memory is allocated for FreeRTOS task by calling c library function Malloc(). Tasks will be stored in heap memory. Each task shares memory in the FreeRTOS. Suppose there are two tasks, so dynamic memory is allocated for the first task, when it is executed, the same memory is given to the second task.

I have come to the conclusion that each task in FreeRTOS shares memory
 

Papabravo

Joined Feb 24, 2006
17,228
Dynamic memory is allocated for FreeRTOS task by calling c library function Malloc(). Tasks will be stored in heap memory. Each task shares memory in the FreeRTOS. Suppose there are two tasks, so dynamic memory is allocated for the first task, when it is executed, the same memory is given to the second task.

I have come to the conclusion that each task in FreeRTOS shares memory
No this is likely to be incorrect. The heap is used for "data memory" for the tasks. It is allocated when the task is created and freed when the task is destroyed. Temporary memory is allocated on the stack, and "code memory" is statically allocated prior to being loaded into memory. Subsequent to the task creation process, a task can dynamically allocate and free memory for the purposes of an application, but the data for managing the task is allocated when the task is created, and freed when the task is destroyed.
 

Papabravo

Joined Feb 24, 2006
17,228
It may also be worth pointing out that processor and memory technology have evolved quite a bit in the last 60 years. What was true then may no longer be valid. You would be wise to specify more details about the environment in case it differs substantially from a single 32-bit processor with exclusive access to a small but not insignificant amount of memory (say 1 Megabyte).
 

nsaspook

Joined Aug 27, 2009
8,894
It may also be worth pointing out that processor and memory technology have evolved quite a bit in the last 60 years. What was true then may no longer be valid. You would be wise to specify more details about the environment in case it differs substantially from a single 32-bit processor with exclusive access to a small but not insignificant amount of memory (say 1 Megabyte).
The scientific computing principles haven't changed much in those 60 years. What changed is what's possible for a few dollars now was millions in dollars and man-hours not so long ago. When I look at what IBM was doing with technology for the moon rocket it's amazing how advanced it was for the time.
 
Last edited:

Papabravo

Joined Feb 24, 2006
17,228
The scientific computing principles haven't changed much in those 60 years. What changed is what's possible for a few dollars now was millions in dollars and man-hours not so long ago. When I look at what IBM was doing with technology for the moon rocket it's amazing how advanced it was for the time.
When I was a graduate student (1969-1970) I thought the study of "memory hierarchies" was probably a waste of time. I'm glad I didn't hold on to that impression for very long.
Earlier this spring I took a look at the APG (Apollo Guidance Computer) and the DSKY. Quite incredible for the time, which was pre-TTL.
 
Last edited:
Top