Working with stl:list and stl::vector types under interrupt handlers I want to avoid malloc() calls.
The question: What is a best way to prevent malloc() calls in STL list and vector? Is it enough to create structure with predefined size and then avoid push/pop/erase calls?
Thank you in advance
For std::vector that should be sufficient. I don't think anything guarantees that though. Memory allocation is considered an implementation detail. If you can restrict yourself to a specific size, I suggest going with a simple static array instead. That way, you have a fine-grained control over what exactly happens.
STL containers like std::list and std::vector have constructors accepting an Allocator type. By supplying your own allocator instead of using the default you are able to control how the container allocates memory. This option is rarely used, but using your own allocator in a real time environment is a good example of where this feature is useful (and proves that the designers of STL did a very good job).
The requirements for you custom allocator type is described in 20.1.6 in the C++ standard
Interrupts are not mentioned in the C++ standard (although signals are), so the standard cannot tell you which operations are safe in interrupt context. The situation is in essence the same as for thread-safety -- you need to consult your implementation for what additional guarantees it offers relating to the new concepts it introduces.
In practice, I expect that the operations on vector which are guaranteed to leave iterators valid will not allocate or free any memory (assuming of course that assigning values to the members of the vector does not itself allocate memory in a copy constructor or operator=). They certainly won't re-allocate the vector's internal storage buffer: the standard guarantees this in terms of when "reallocation" is or is not permitted to occur. There's nothing else you'd expect vector to need allocated memory for. If you ensure ahead of time that the vector has sufficient capacity, then once you're in interrupt context you can push_back elements, or assign to them, and guarantee that the vector will not reallocate its contiguous storage, and therefore have strong reason to believe it won't allocate any more memory.
What it might do, though, is cause assigned virtual address space to be committed that was not previously committed. I don't know whether or not that's safe in interrupt context. Ensuring ahead of time that the vector has sufficient size, not just capacity, should mean (with a suitable constructor of course) that all the memory is written to and hence committed.
list is different: it has no excess capacity, and can allocate and free list nodes as items are added and removed. I'd expect an intrusive list to be usable in interrupt context, though, or you could create a list of "zero objects" and then assign to the elements, in the same way you can with vector.
Still, that's just based on expected/typical implementations. The standard doesn't prevent vector from allocating and freeing a few blocks just for laughs, or for obscure platform-related reasons.
Just one other thing to add: a const std::vector will not cause allocations. So if your interrupt handling code doesn't change the vector, declare it const and the compiler will make the vector stays the same.
As onebyone.livejournal.com mentioned, the C++ standard does not say anything about interrupt handlers. It does talk about signal handlers, but even then it's a very gray area. About the only thing you can do inside a signal handler that's guaranteed to have well-defined behavior across all conforming C/C++ implementations is assigning to a variable of type sig_atomic_t and returning, e.g.:
sig_atomic_t flag = 0;
// This signal handler has well-defined behavior
void my_signal_handler(int signum)
{
flag = 1;
}
int main(void)
{
signal(SIGINT, &my_signal_handler);
while(1)
{
doStuff();
if(flag)
{
flag = 0;
actuallyHandleSignalNow();
}
}
return 0;
}
Although in practice, you can almost always get away with doing a little more inside your signal handler.
It sounds like you want to preallocate memory in your initialization code, so that your interrupt handler can avoid heap allocations. I'll assume that the elements you're storing in these containers do not themselves perform any heap allocations, because that would complicate the answer.
You can preallocate memory for std::vector by calling the reserve() method. Methods like push_back(), pop(), insert(), and erase() manipulate the vector's size (the number of elements it currently contains). They only affect the capacity (the number of elements it has room for) when the new size is larger than the current capacity. reserve(x) ensures that the capacity is greater or equal to x, increasing the capacity if necessary. (Also note that the only operation that ever decreases a vector's capacity is swap(), so you don't have to worry about erase() reducing the vector's capacity.)
This approach won't work for std::list, but there's another approach that will: preallocate list elements by inserting them into a "spare" list. Instead of inserting new elements, use the splice() method to move them from the "spare" list to the "primary" list. Instead of erasing elements, use the splice() method to move them from the "primary" list to the "spare" list.
As a testimonial: we use two methods mentioned in other answers at my workplace:
Mostly we do these two things to avoid fragmentation, decrease allocator overhead, eliminate the copy-on-grow penalty, etc. But sometimes (especially with e.g. the instrumenting profiler) we want to absolutely avoid allocation during an interrupt handler.
Usually, however, we avoid issues with interrupts and allocations in other manners:
Note that lock-free data structures could be an alternative to the second bullet here, we haven't set up and done profiling to see if it would help. Designing your own is tricky business anyway.
Paranoia is the better part of valor for interrupt handlers: if you're not certain what you're doing will work, it's sometimes much better to approach the issue in an entirely different manner.