Are deallocations safe to do on a real-time thread?

1

Couldn’t find an answer for this anywhere else.

We all know that allocating memory on the audio thread is bad:

void processBlock(AudioBuffer<float>& buffer, MidiBuffer&)
{
    std::vector<int> myData(1000); // BAD!
}

But what about deallocating memory?

std::vector<int> myData(1000); // Allocate on message thead.

void processBlock(AudioBuffer<float>& buffer, MidiBuffer&)
{
    myData.clear(); // Yay, or nay?
}

Edit:
Looks like std::vector::clear wasn’t the best example since it seems it can reallocate memory but is not guarenteed to do so (http://www.cplusplus.com/reference/vector/vector/clear/).

2

deallocating memory have the same issue with the allocation system locking…but a vector.clear() do not deallocate memory

https://stackoverflow.com/questions/13944886/is-stdvector-memory-freed-upon-a-clear#:~:text=The%20vector’s%20memory%20is%20not,the%20elements%20after%20a%20clear.&text=Removes%20all%20elements%20from%20the,due%20to%20calling%20this%20function.

1 Like
3

The std::vector<int> myData(1000); is actually done on the stack, so I don’t see any RT issue here.

4

The vector object itself is on the stack, but its data is allocated on the heap. Stack objects must have their size known at compile time. If the object can change its size at runtime, it has to allocate. That’s why std::array’s size is a template argument.

1 Like
5

But is this specific case the size (= 1000) is known at compile time. Assuming the code does not push more than 1000 items, this should be safe yes?
(But OK std::array is a better choice…)

6

Nop, std::vector always allocate on the heap even if the size is known at compile time or this is a specific non std compiler optimisation.
Some stuff like std::string have a small string optimisation but I doubt vector have one in any case and 1000 is clearly not a small size.
if you want on the stack then indeed std::array is the way to go.

1 Like
7

The initial size is a compile time constant, but a vector can be resized. Anyway, the point was mainly that there needs to be a known size for every type, because sizeof(T) is a compile time constant. For example, sizeof(std::vector<int>) is 32 bytes in MSVC on Windows x64. There’s no size information in the type itself -it’s 32 bytes whether it holds 10 or 1000 ints. Small buffer optimization (for std::string, std::function) is done by oversizing the type a little so that it can hold small data within itself. I don’t think any implementation does that for std::vector -there’s not much use for it.