[SciPy-dev] LAPACK is not thread-safe (AFAICT)

Robert Kern kern at caltech.edu
Sun Sep 2 21:59:26 CDT 2001


Disclaimer: I'm not a FORTRAN programmer or a thread expert.

In linalg/docs/more_notes, Eric says he knows of no reason that any of the
LAPACK functions wouldn't be thread-safe. However, I have run across a USENET
discussion saying that some are not thread-safe. Some of the Netlib LAPACK's 
functions use FORTRAN's SAVE statement to preserve variable values across
invocations, and this makes them thread-unsafe (AFAICT).

C.f.
http://groups.google.com/groups?q=LAPACK+thread&hl=en&safe=off&rnum=1&selm=ceee3b79.0108241520.57157bb6%40posting.google.com

The affected routines are dlacon, dlaed6, dlamch, dlartg, dlasq3, dlasq4, 
zlacon, zlargv, zlartg, and their single-precision equivalents. Also, any
function calling one of these functions is not thread-safe either.

ATLAS is thread-safe, but of course, not all of the LAPACK routines have been
integrated. Some vendor LAPACK libraries appear to be threadsafe.

I don't know how useful this information is; I just wanted to throw it out
there before someone adds the Py_BEGIN_ALLOW_THREADS to the wrappers.

-- 
Robert Kern
kern at caltech.edu

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter



More information about the Scipy-dev mailing list