LAPACK Archives

[Lapack] Thread safety of LAPACK

Dear all,

first of all I would like to thank you for your work on LAPACK.

I am using this library on multiprocessor machines, and I encountered
something that seems to be race condition when enabling a relatively large
number of threads (order of 8 or more).  In these situations, occasionally
the program fails.  I believe this is due to LAPACK (because I have a
different version of the same program that uses slower GSL routines and
works without problems), and during one of the debugging sessions I was able
to track the problem to the frequent (LAPACK internal) calls to DLAMCH.

In summary, the problem I encountered seems to be very similar to the one
reported in

http://icl.cs.utk.edu/lapack-forum/archives/lapack/msg00342.html

The reason why I am sending this email is twofold.

- First, I would sincerely hope that in the next versions of LAPACK this
issue will be considered, so that one can finally rely on a complete thread
safety (if one retains from using the old, thread-unsafe versions of a few
functions as listed in the LAPACK documentation).  In this respect, let me
add a possible solution: one could either test the IEEE at compilation time
(as suggested already), or even generate the sources fo xLAMCH by inserting
there some hard-coded values calculated at the compilation time using the
same technique employed by the current implemention of xLAMCH (that would be
the advantage of working on non-IEEE machines).

- Second, I would like to propose a workaround for all guys that (like me)
cannot or do not want to recompile the whole library.  The solution, in this
case, is to create two thread-safe versions of the {S,D}LAMCH functions (for
example, by hard-coding the proper values for the machine where this fix is
used), and to compile them as a dynamical library (flags are OS dependent,
but on Linux for example one would needs to use something like -fPIC and
-share on the gcc flags).  Finally, each execution of programs linked
against LAPACK should be performed by setting appropriate environment
variables to force the load of the newly created dynamical library
(LD_PRELOAD for Linux, DYLD_INSERT_LIBRARIES for MacOSX...).  This is
clearly a dirty trick, but might help unless we get a thread-safe version of
xLAMCH.

Best regards,
Marco Lombardi
ESO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://lists.cs.utk.edu/private/lapack/attachments/20080626/f8739aab/attachment.html
 

<Prev in Thread] Current Thread [Next in Thread>


For additional information you may use the LAPACK/ScaLAPACK Forum.
Or one of the mailing lists, or