LAPACK multi-thread issue

By mmaggion at Thu, Jul 16 2009 5:00am |

Dear all -

I have a C++ program calling dgesvd_ from the LAPACK library in the veclib framework in Mac OSX 10.5.7. It is supposed to be thread-safe, provided that the
calls
(void) dlamch_("e");
(void) slamch_("e");
are made before calls to dgesvd_ are made from multiple threads. I do do those calls at the very beginning of my main(), before any multiple threads are created. Even so, if I don't protect my calls to dgesvd_ with a mutex, I get errors from dgesvd_. More specifically, dgesvd_ fails returning info=1 (failure to converge). This does not happen (ever) when I have a mutex protecting the call. All the variables/parameters passed to dgesvd_ are allocated by each thread, so there should be no conflict there. I use POSIX threads and include the pthreads library.
Is LAPACK thread safe or not? Am I missing compilation flags? It shouldn't matter, but I am using Eclipse and g++ to compile and link.

Many thanks for any hints/explanations. Regards,

Mauro

‹ Flow chart software fro charting code Apple Cluster Implimentation ›

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Fri, 2009-07-17 10:00 — msa

The problem could be

The problem could be internal calls to dlamch/slamch:
http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg00479.html

Sat, 2009-07-18 20:58 — mmaggion

Re: The problem could be....however

Thank you very much for the suggestion - I had seen those posts and I only very partially understand them.
This seems to be related to the following errata on Apple's website:
http://developer.apple.com/hardwaredrivers/ve/errata.html
where however a call to slamch and dlamch is supposed to fix the problem.
Maybe I should just create separate processes rather than separate threads - I have not done that in MAC or Unix, but it can't be that hard. I am just very surprised to see that thread-safety isn't an issue of the past for these widely used libraries.