deterministic free store using memory pools
-
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?
-
-
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?
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-2Regards
-
-
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.
-
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.
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
-
@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.
-
Also, there is
std::arraycontainer which doesn't have any dynamic allocation and is just a convenient wrapper around C array of fixed size -
@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
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!
