OpenMP Mex files : static TLS problem

Recent versions of Matlab have a problem with running out of DTV slots for shared libraries loaded at runtime with the "initial-exec" TLS option.

Unfortunately the omp libs (libgomp / libiomp) are all use initial-exec for performance reasons.

They may work, but often the "static TLS" error from Matlab results, eg if some commands like 'doc' or other modules are loaded before hand.

More information here:

http://stackoverflow.com/questions/19268293/matlab-error-cannot-open-with-static-tls http://www.mathworks.de/support/bugreports/961964 http://www.mathworks.com/support/bugreports/1003952

This is really a devastating regression for my work (there was no problem at all with versions R2012a and earlier) and I am desperately looking for any sort of workaround.

At the moment the only thing I can think to try is to build my own GCC toolchain with libgfortran, libgomp etc. with fPIC and libgomp without initial-exec... so I can link everything statically into my mex file. But I understand this could have serious performance consequences for the openmp code which sort of defeats the point.

Is there any way then to use OpenMP within mex files? (is there a way to link against Matlab's libiomp?

Answer 1

[Robin]

Mathworks were very helpful with resolving this problem.

Any library with thread local storage uses a DTV slot when it is opened, of which there are only a small number. Libraries which use the initial-exec model require a slot and will fail to load if one is not available. Libraries using other model can load anyway even if there is no slot free. This is why there is an asymmetry (ie trying to call the openmp code after calling 'doc' in a fresh matlab fails, but if the openmp mex file is called first, 'doc' works fine).

So the simplest solution is to LD_PRELOAD any initial-exec libraries that may be required. In my case: LD_PRELOAD=/usr/lib/gcc/x86_64-redhat-linux/4.4.4/libgomp.so matlab Then these will all get a slot, and the things that would otherwise fill that slot won't be affected.

Another solution was to switch to the Intel compiler, so that the generated mex file can load the libiomp5 which is distributed with Matlab.

[Feimo Li]

Really a great help, helps a lot to solve this frustrating problem for me! Thanks a lot

[Denis Anikiev]

In my case the problem was also with OpenMP library. Adding this to .bashrc

export LD_PRELOAD=/usr/lib/gcc/x86_64-linux-gnu/4.8/libgomp.so

solved the issue. System is Debian GNU/Linux 8.7

Answer 2

[Martijn]

If you want to make use of OpenMP, please follow this workflow:

https://www.mathworks.com/matlabcentral/answers/237411-can-i-make-use-of-openmp-in-my-matlab-mex-files

where you do not use libgomp at all and instead use libiomp which is included with MATLAB. This a) prevents static TLS issues with libgomp and b) provides better compatibility (e.g. a MEX-file linked against libiomp can be cleared whereas MEX-files linked against libgomp may cause a crash when cleared (this is a libgomp, not a MATLAB issue, libgomp was never designed to be unloaded from a process)).

[David Rigie]

I am interested in the solution linked above, but the link appears to be broken now. Do you have another reference explaining the described workflow?

Answer 3

[Sergio Duarte]

If you want you can look this:

https://uk.mathworks.com/support/bugreports/1113424