Note Intel’s MKL implementations of BLAS/LAPACK are already multi-threaded, so it is likely that you won’t achieve a vast improvement (the overall performance could even be harmed) in doing this, unless you ensure BLAS calls use single threading.

I spent a few hours (days…) writing a mexFunction that mimics the functionality of MATLAB’s pagefun but on the CPU. I put the call to mexCallMATLAB inside a #pragma omp parallel for loop, so essentially it calls the builtin functions (e.g. eig, svd, inv, etc.) rather than recreating all the LAPACK interfacing in C++. It works on a single thread but crashes if num_threads > 1. Any ideas what cardinal rule this is breaking?

I changed the size of matrices from 4 to 10000, i.e. matrix1=rand(10000) and matrix2=rand(10000);
Then, I compared the speed in terms of the number of the threads.
For Nthreads=1 and Nthreads=4 the runtime is almost the same!!! I do not know why?!?!

One multithreaded mex file I can’t say enough good things about is getmatvar which, in addition to being faster than MATLAB builtins (i.e. matfile objects), allows you to read part of a struct without loading an entire mat file!

Also worth checking out is mexthread if you have a compiler with std::thread

I’ve seen a couple mex files pop up which use the BOOST library as well, but I can’t think of one at this moment. Maybe another reader can link to an example.

@Andy – In general I believe that it is better to use MEX’s mxMalloc/mxCalloc/mxRealloc/mxFree than their ANSI-C counterparts. This will ensure that all the MEX function’s memory is properly and automatically managed by Matlab’s memory manager, reducing the likelihood of segmentation violations and memory leaks. I admit that I did not follow my own advice in the code presented here. It doesn’t make much difference if you allocate and free the memory properly, but using the mx* variants is a bit safer in general.

Note that using mxFree to deallocate memory that was originally allocated using mxCreate*, or conversely using mxDestroyArray to deallocate memory that was originally allocated using mx*alloc, leads to a segmentation fault – mx*alloc should always and only be used with a corresponding mxFree, and similarly mxCreate* should always and only be used with a corresponding mxDestroyArray.

Another error occurs when trying to mxDestroyArray or mxFree within a C++ destructor, since at that point the memory manager has already freed the data.