Difference between dynamic and static allocation in Mex files

what is the difference between allocating array in mex using mxMalloc and by declaring an array

example:

double a[200];

double* a = (double*)mxMalloc....

I want to use threads so I want to avoid using mxMalloc but I don't want to use malloc. can I use static allocation (I'll take bigger arrays with length parameter or something) thanks,

Answer 1

[Walter Roberson]

If you declare something as

double a[200];

inside a function, then it will be statically scoped, and will disappear when the function returns.

If you make the same declaration outside of any function, then it will be file scoped and will exist until the program exits.

If you use

extern double a[200];

outside of a function then you are making reference to a static global variable that will be accessible in any other file as well. At most one of the "extern" references at file scope can initialize the array.

Notice that static variables (declared at file scope) are fixed size and come into existence when the program is loaded. If you want something that does not exist until it is needed, or something that can be variable size, then you need to use dynamic allocation.

Answer 2

[Jan]

If you use thread, it is not a question of wanting, but you must avoid mxMalloc from inside the threads. I do not see a reasons to avoid malloc and free.

A static allocation has the advantage and disadvantage, that the allocated memory is still occupied when the function returns. When you need 100MB for 16 threads, 1.6GB RAM are blocked until you clear the mex function from memory. This is much faster than allocating this memory dynamically each time the mex function is called.

[Eyal weinberger]

I looked over in the internet and saw people who warns about using malloc. Do you think that if I'll use it in a thread without any mex functions it will be safe? (as long as I'll use free at the end) are there any restrictions about it?

[Jan]

@Eyal: malloc is perfectly ok and does not cause any troubles, as long as you cleanly free the allocated memory afterwards. Never combine malloc with mxFree or mxMalloc with free.

mxMalloc is smarter, because it cares about forgotten pointers. malloc causes memory leaks, when the function is stopped by an error without free'ing in the error handler. While mxMalloc creates an error message when the allocation fails (in a MEX file), you have to check the result of malloc manually if it is NULL. But in a clean program you can catch all occurring difficulties (not problems!) easily.

[James Tursa]

@Eyal: One other difference I don't see mentioned is that declarations such as "double a[200]" typically cause the memory for the variable to be allocated off of the stack, which is relatively limited in size, as compared to malloc (and friends) which allocate memory off of the heap (*much* bigger than the stack).

Also, to get malloc'ed memory free'd if a mex routine exits abnormally one typically must employ the mexAtExit function (see the doc) and other cleaning functions (that you the programmer would write) and have the pointers themselves at the top level (outside any function) so that their values are not lost when the mex routine exits.

[Jan]

@James: When a crashing Mex function is a rare exception, it might be enough to inform the user that a restart of Matlab is recommended. Am I right that this clears up leaked memory reliably?

For explanations about an exhausted stack space see http://en.wikipedia.org/wiki/Stack_overflow. Unfortunately these explanations are not clear: It depends on many parameters how large the stack is and if it is too small, the function crashes. Not really useful.