DORMQR and thread safety

[patperry]

Dear LAPACK team,

Thank you for your excellent work on this fantastic library!

I have a question regarding routines like DORMQR. This routine modifies one of its input arguments (A), and then restores it on exit. As I understand it, this means that DORMQR is *not* thread-safe; if two different threads try to use the same matrix as the input argument (A), then at least one of the threads may compute the wrong answer. If thread one tries to restore "A" before thread two is done using it, then thread two will compute the wrong answer. Is this reasoning correct?

The MKL documentation (at http://www.intel.com/software/products/ ... ormqr.html ) doesn't mention modifying or restoring input arguments, so I assume their version *is* thread-safe.

Am I wrong here? Could someone please straighten me out? I couldn't find any mention of this issue on the web.

Thanks in advance,

Patrick O. Perry
Department of Statistics
Stanford University

[Julien Langou]

DORMQR is thread-safe of correctly used. The header specifically says that "A is modified by the routine but restored on exit". Therefore using DORMQR with two concurrrent threads and same INPUT A is not safe.

It is the second time we have this problem report. The first time it was mentioned to us by Gregorio Quintana-Orti and Robert van de Geijn. I believe the quick way to improve the understanding of the interface is to move A as an INPUT/OUTPUT variable in the interface. (The restrictions come from DLARFT and this is how the interface looks like so the code would look more homogeneous that way.) In the wish list of LAPACK-3.2 from Nov 2008, see http://www.netlib.org/lapack/lapack-3.2.html#_10_expected_additions_and_improvements_for_the_future, there is an item "make xLARFB thread friendly" which addresses your point.

Regarding Intel MKL, I can see that the header of their DORMQR is slighlty different than ours and they have removed the statement: "A is modified by the routine but restored on exit", therefore I believe the argument A in their DORMQR is INPUT only so that it is safe to call DORMQR from two different threads with the same input A. The best is to ask them!

Best wishes,
Julien.

[gmh]

The MKL team went through a bunch of routines to fix this INPUT/OUTPUT situation in our LAPACK codes. For instance, MKL's DLARFT (that Julien mentions) has been thread-safe since MKL 10.0. However, despite what our documentation says, MKL 10.1's LAPACK has an issue with DORM2R still, which can be called by DORMQR for small sizes. A similar thing can be said about other functions in the ?ORM(LQ/QL/QR/RQ) family. We're in the process of fixing this.

Thanks,
Greg Henry (MKL Architect)