Misra C, RTOS, and inter-thread communication

Question

Currently I am developing an embedded system, running multiple tasks within an RTOS on a heavily constrained (mainly memory-wise) system.

My team-lead advised the use of dynamic memory allocation. However, safety-critical standards like MISRA C advise against it.

So what are the sensible alternatives? Creating shared memory and handling it with mutexes / gates? Currently I am dynamically allocating memory and passing pointers to it between tasks, but I would greatly appreciate some insight on how to improve this design.

Some more info: The embedded system's goal is to a central communication module, communicating with several outside systems. These outside systems want information from the different tasks on the embedded system, and vice versa.

To accomplish this, all tasks must communicate with that communication module. This is currently done by dynamically allocating storage for that message, and passing the pointers between the tasks. The receiving task then frees the allocated memory. The choice for dynamic allocation was made because most tasks will not communicate very much, while our hardware platform is very memory-constrained.

Answer 1

Unconstrained dynamic allocation in a resource constrained (embedded) system is a bad idea, because it will quickly become impossible to tell if you have enough memory to satisfy all allocation requests. This is considered especially problematic for safety-related software, because it might mean that a safety function can't be performed.

Sometimes, dynamic allocation can't really be avoided. In such cases, the advise is to do the allocation at power-up and never release the memory. That way, you at least know shortly after power-up if there is a problem with the required amount of memory, rather than getting reports that the device suddenly fails after weeks of operation.

In the case of a message queue, the usual solution is to use "dynamic allocation from a dedicated pool". You statically allocate a message pool that is large enough to hold "a sufficient number" of the largest messages. When one task needs to send a message, it requests one from the message pool and transfers the pointer to the message to the receiving task, who will return the message to the pool after handling it. The message pool may need to do some locking to protect its internal administration from concurrent access.

If the message pool hands out fixed size blocks, then this is relatively safe, as you only have to account for the possibility that the total number of concurrent messages is too large, but there is no rist of "losing" memory due to fragmentation.

More elaborate schemes are possible to use variable-sized messages without fragmentation.