Dear Jeremy,
Many thanks for your input. We are aware that xLAMCH is not thread
safe, although we did try to improve its chances of not meeting a race
condition. Your example is interesting and is the first time I can
recall that xLAMCH has actually failed. Here is what is said about
thread safety at:
http://www.netlib.org/lapack/lapack-3.1.0.changes
for LAPACK version 3.1:
"All the LAPACK routines are now thread safe except {s,d}LAMCH and the
triplet {c,d,s,z}lacon.f, {d,s}lasq3.f and {d,s}lasq4.f. By thread safe,
we mean that your LAPACK library will be thread safe provided that your
compiler is. Regarding the 10 routines still containing DATA or SAVE
statement:
{s,d}LAMCH can be manually replaced by thread-safe routines (e.g. using
F90).
{c,d,s,z}lacon.f, {d,s}lasq3.f and {d,s}lasq4.f are left in LAPACK for
backward compatibility, they are flagged as deprecated, and represent
dead codes in this current release (v3.1)."
I would suggest that you replace your 'vanilla' version of DLAMCH with a
version that explicitly returns the required constants. If you do a
make lapack_install
in the top level lapack directory and then run the testdlamch executable
in the INSTALL directory, you can then see the relevant constants. On
my IEEE 32 bit Pentium M laptop I get:
Epsilon = 1.1102230246251565E-16
Safe minimum = 2.2250738585072014E-308
Base = 2.0000000000000000
Precision = 2.2204460492503131E-16
Number of digits in mantissa = 53.0000000000000000
Rounding mode = 1.0000000000000000
Minimum exponent = -1.0210000000000000E+03
Underflow threshold = 2.2250738585072014E-308
Largest exponent = 1.0240000000000000E+03
Overflow threshold = 1.7976931348623157E+308
Reciprocal of safe minimum = 4.4942328371557898E+307
Again, many thanks for giving us such useful information.
With best wishes,
Sven Hammarling.
|