Re:The Power of 10: Rules for Developing Safety-Critical Cod...
by eschneider on Wednesday June 28, 2023 @01:11PM
(#36509422)
The problem with dynamic allocation (aside from the problem that it can fail) is that calls to malloc don't complete in a predicable time, so it's pretty much verboten in hard realtime apps. Pool allocators can (though not always are) written to return in a bounded time, so if it's created at startup, yeah, not really dynamic allocation.
[ Parent
| on HN ]
Re:The Power of 10: Rules for Developing Safety-Critical Cod...
by AlotOfReading on Wednesday June 28, 2023 @01:53PM
(#36510068)
They're not meaningfully different from the perspective of the programmer. You call a malloc-like function and get some memory back. The total dynamic memory use of the application is simply capped. You can do this even with libc malloc in a standards compliant way (e.g. Broadcom used to ship a malloc implemented as a series of pool allocators over statically initialized arenas), it's just uncommon.
Re:The Power of 10: Rules for Developing Safety-Critical Cod...
by AnimalMuppet on Wednesday June 28, 2023 @01:58PM
(#36510140)
If you're the programmer who has to provably meet hard real time constraints, the difference matters quite a bit.
Re:The Power of 10: Rules for Developing Safety-Critical Cod...
by JohnFen on Wednesday June 28, 2023 @06:34PM
(#36513587)
> You can do this even with libc malloc in a standards compliant way
This is what I do in nontrivial embedded projects. It makes things easier and less error-prone to replace malloc()/free()/etc implementations directly with ones that behave as needed. And then you don't have the standard implementations sitting around waiting for a new dev to accidentally use them.