>>106323345
>but aren't random allocations required by some parts of C++ stdlib
sure, and IEC61508 or MISRA C++23 don't explicitly forbid dynamic allocation even in safety critical systems
during runtime its not advised or might be outright forbidden, but you are free to use it at initialization
some stl containers are const or constexpr compliant so you can work around some of those issues if you need to
others like the ranges and views contain methods that dont use dynamic allocation, so some of these are good too
and if you really really must need dynamic allocation you can create your own allocator you can hate when it doesnt work well
no RTOS i know of for micro controllers has good support for C++ threads or even pthreads for that matter
its all just OS-provided threading (Β΅-velOSity, FreeRTOS, SafeRTOS, SYSGO, eSOL)
the overhead for pthreads is not worth it on this level and apparently implementing support for C++ threads is not something RTOS OEMs do
OSes for microprocessors such as Zephyr, Integrity, QNX, et.al. do generally support pthreads, not sure about C++ threads though, these OSes arent my area of expertise
anyway, async behavior or execution policy things in the C++ language arent always supported by the OS
and this is particularly tricky if we look at mutexes and such that OSes generally provide their own construct for
i've grown a habit of wrapping these in lockable-compliant containers and then using the locks from C++
but std::lock contains a deadlock-avoidance algorithm that may call yield on the executing thread
when do you ever have a free-standing, heapless environments? no useful micro controller has so little RAM that you cannot allocate a 4k heap