Implemented heap_6 for C++ real-time applications

[jnorre]

Hi Sven,

Johnny from Denmark. Nice to see you provided an example. Thanks!

I also thought about this, but none of Your heaps is really working.

What do you mean? All of the heaps are working as described! FreeRTOS is used right now with these heaps in production software, safety critical software and in aviation software.

heap_1 doesn't allow deletion heap_2 is worse than heap_4, both won't get certified heap_3 redirects to the standard-heap, also not certified heap_5 heap_4 with multiple regions heap_6 multiple regions and almost ready for certification -> Heap

What certification(s) are you talking about (do you have a specific ISO, EN or DIN standard in mind)?

When danielglasser (https://forums.freertos.org/u/danielglasser) talk about DO-178B not allowing deallocation, then it has nothing to do with the existing heap managers or with malloc/free as provided by the compiler - it is a requirement by the standard because this leave less points where the program can fail. Same with MISRA: Analysing what causes programs to crash and then making rules for how to make your program to avoid these pitfalls. Your heap changes nothing in this regard.

With your example I tried to test the code for the two things I value for embedded projects: Speed and memory usage/overhead. The test (after setting configUSE_MALLOC_FAILED_HOOK to 0) using 100 bytes memory block was as follows:

heap_5.c   Can allocate 405 blocks 
           1000000 malloc/free took 87 ms.
heap_6.c   Can allocate 451 blocks 
           1000000 malloc/free took 356 ms.

So your heap wins on number of allocations, but lose on time. Thats actually nice! However, heap_5.c is normally not used that much as we often can allocate static variables in the non-contiguous blocks, so here is the results for a contiguous memory area of mainREGION_1_SIZE+mainREGION_2_SIZE+mainREGION_3_SIZE (configTOTAL_HEAP_SIZE set to 50913 bytes):

heap_2.c   Can allocate 454 blocks 
           1000000 malloc/free took 79ms.
heap_4.c   Can allocate 454 blocks 
           1000000 malloc/free took 85ms.
heap_1.c   Can allocate 509 blocks 
           1000000 malloc/free took 73ms. (modified to allow test)

As you can see these three heaps are faster and has less overhead.

An observation: Your code does not respect the configUSE_MALLOC_FAILED_HOOK flag - it indicates that a failed allocation should call the provided vApplicationMallocFailedHook function instead of returning NULL.

So from my point of view, your memory manager seems to have a nice use case for multiple non-contiguous memory blocks, not at least because it can provide more allocated blocks than heap_5, but only if it is okay that it takes more time to allocate/deallocate.

Best regards, Johnny Norre

[jnorre]

Hi,

thanks for Your reply. Please don't get angry because i think Your heaps don't work, they just don't work for me. As You can imagine, i have a lot more memory and multiple cores in my modern C++ application. I just want to be sure the heap won't slow down after a few days of operation.

I don't get mad, but I get mildly annoyed when you can't see that the most common use of FreeRTOS are for embedded programming, where the resources (processsing power, flash memory and RAM) are very limited. The Win32 example is not even a good demonstration of FreeRTOS tasks or memory usage, as it maps to Windows threads and uses Windows stacks, which are two of the more memory consuming things in a embedded FreeRTOS based program. The Windows port is good for simulating an embedded program to try out concepts in an unlimited environment, but it is not used to make Windows multi-threaded programs.

I'm a hobby-programmer without any restrictions, i compile my C++ application right into the kernel. Probably there is no certification for this, this would be nice. VisualStudio debugging, IntelliSense and modern C++ should be enough to get an application running reliably with some experience.

And many of us using FreeRTOS are professional programmers which make actual programs for actual devices. The certification we talk about is e.g. software for heavy machinery, where peoples health or lives is at risk if a controlling device or the software running it crashes. For this reason, there are some international standards we have to adhere to and often an actual certification process of the system (hardware, software and the system it controls) performed by certification bodies. Please respect, that some people has used FreeRTOS for a long time and maybe, just maybe have a little bit of more knowledge of how it works and what it needs, than other people.

Thank You again for the benchmarks! Your problem is getting more and more unusable gaps, slowing down the heap over time. Maybe it is just my imagination, but Tesla seemed to have problems nobody knows how to solve but me. Their AI is an illusion in my eyes. It was trained with modern C++ and will never get my insurance like You.

I've heard Mr. Musk talk about software stuff from time to time (AI included) indicating he has little to no actual knowledge about the science or programming behind it. He is an excellent business man, however - respect for that.

Your heaps may be faster, but not for every application on the long run. I'm going to put my implementation into MemMang today, for future use.

Thank you! As mentioned, after you made the example and used time to implement it for FreeRTOS, some people might find use for it. From my experience with the thing I have worked on (heavy machinery like cranes and foresting machines, earbuds, multiple surveillance systems) heap_2 is mostly used (maybe heap_4 for newer projects), followed by heap_1 and heap_3. Heap_5 is a niche as most embedded systems does not have the discontinuous memory that it is used for. However, more and more new microcontrollers seems to have more complex memory maps, so it might be more useable in the future.

Best regards, Johnny Norre

[aggarg]

Thank you sharing your heap implementation. You should be able to use your heap with FreeRTOS without any issue. Please let us know if that is not the case and any support from the FreeRTOS Kernel is needed.

As far as keeping the implementation goes, I think the best way to proceed would be to create an example using this heap, possibly showcasing its strengths, and putting it in the following repository to make it available to the community - https://github.com/FreeRTOS/FreeRTOS-Community-Supported-Demos. Since you already host your heap on GitHub, you should be able to consume it in your example using CMake FetchContent (or some other similar mechanism in your build system).

Please let us know if you are good with this and I will close this PR.

Thanks again!

[sonarcloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud

[RichardBarry]

Thanks for your PR, and enthusiasm for the topic. Having reviewed the code, I agree with aggarg@’s post – hence closing the PR here in the hope you create a PR in the community contributions repo as the best way of making this code available. I feel the code is a little more complex than users expect for FreeRTOS, and from some of your comments, may contain issues. Plus, some of the novelty would require signing of a Contributor License Agreement as mentioned at the bottom of the CONTRIBUTING.md file, which would then trigger escalated reviews on our side.

[svenbieg]

I fixed my issue, it is ready for certification.

heap_6.zip

Good bye!