deterministic free store using memory pools

Kent-Dorfman

A network programmer who works with me opened the door on using C++ on our project. Embedded rules are pretty strict about preferring C to C++, and a lot of caveats if you do go with C++, so while I'm somewhat happy about him opening that door, I'm also a bit scared about the risk to code safety and determinism. In the long run I do think it's the right move though, since C++11 design will take about 1/3 the time of designing and testing in pure C.

Anyway, a big no-no in safety critical C++ embedded code is the free-store or heap. Some of the problems can be mitigated by only using memory that has been allocated during the initialization phase. However, free-store usage is implicit in most of the STL containers. The common work-around is to replace the default allocator with one that has deterministic behaviour.

My question is two-fold:

what are the pros/cons of subclassing the STL templates to replace the default allocator such that std::vector becomes deterministic::vector and has its own allocator, or as a different option, simply globally replacing the new and delete operators?
what are some good deterministic allocator reference implementations that can manage memory pools using tunable fixed size buckets?

Thoughts?

aha_1980

Hi @Kent-Dorfman,

I'm an embedded programmer too, and currently only using C with static allocated memory (i.e. malloc at the start of the application, and never use free). I'm not sure how you handled that so far?

In my opinion, C++ is as good or better as C, if you don't use dynamic memory allocation at runtime. And if you do, from what I've heard about the topic, using pool allocators can gain you pretty much.

You might want to read the following Qt blog posts, which describes the work that has been done to add a pool allocator to Qt:

https://www.qt.io/blog/a-fast-and-thread-safe-pool-allocator-for-qt-part-1
https://www.qt.io/blog/a-fast-and-thread-safe-pool-allocator-for-qt-part-2

Regards

Kent-Dorfman

I see a lot of memory use profiling in my future, and then tuning the discrete buckets to meet the expected needs. Will look at the pool allocators, but Qt itself won't end up on the vehicle: maybe on some of the support test harnesses as front-end GUIs.

aha_1980

@Kent-Dorfman

Will look at the pool allocators, but Qt itself won't end up on the vehicle

Thats fine, but we can still learn from them. With the MCU offering, they radically slim down Qt and QML and trim it for speed. And thanks to Open Source, they tell us how to do it best.

Regards

Konstantin Tokarev

@Kent-Dorfman said in deterministic free store using memory pools:

However, free-store usage is implicit in most of the STL containers

Not at all. Every STL container has customizable allocator passed as template argument. Boost provides ready to use STL-compatible pool allocators, though it's also possible to roll your own for your specific requirements.

Konstantin Tokarev

Also, there is std::array container which doesn't have any dynamic allocation and is just a convenient wrapper around C array of fixed size

Kent-Dorfman

@Konstantin-Tokarev
I think you're saying I'm wrong and then restating exactly what I wrote in the first place?

The default allocator reverts to the default heap manager and I'm well aware that it can be overriden, as I mentioned that as a potential strategy. so yes, it is implicit in the default STL.

Normally I stay well away from boost. Historically the lack of real boost documentation and frequently changing interfaces have left me severely jaded where boost is concerned. If/when something from boost finds its way into the standard then I'm more likely to give it a whirl, but I may take a look at their pool allocators. Thanks!