Replies: 2 comments
-
I'd recommend we put this is an "extras" library under F´. I like the idea, but am hesitant to support many different flavors of buffer manager. We were asked to maintain the original buffer manager's availability too, and we solved this by putting it in a support library. It is still available to users, but not the recommended component fr general cases. How does this sound? |
Beta Was this translation helpful? Give feedback.
-
This type of component is undoubtedly appealing for embedded software systems with lower reliability specifications than those typically developed in our field. This may allow more stakeholders to participate in or feel involved with the framework. Personally, I always keep in mind that for very high criticality software systems, they largely adhere to MISRA, which still prohibits dynamic allocation in its most recent version, MISRA C 2012 (ref: http://my.ldrasoftware.co.uk/repository/miscellaneous/Misra-c_2012_compliance.pdf). |
Beta Was this translation helpful? Give feedback.
-
The current
BufferManager
allocates buffers from a fixed pool of variable-sized memory buffers. This is the best solution for a real-time environment, since you generally don't want to allocated from a heap after initialization. This is due to the fact that the heap can become fragmented over time and the allocation time can become non-deterministically long. If the system is not real-time, however, it might make sense to use the heap to make allocation sizes more flexible. This would propose a version of BufferManager that would allocate from the heap. When a buffer was requested, it would issue amalloc()
call, and when a buffer was returned, it would issue afree()
call.Beta Was this translation helpful? Give feedback.
All reactions