[windows] sgemm call gets stuck in multithreaded openBLAS

[CascadingRadium]

Summary

calling sgemm_ back to back in a loop causes a thread leak and the control never returns from it.

Platform

OS: Windows 10

openBLAS version: 0.3.26

Installed from: Self Compile

openBLAS compile options:

    cmake `
    -G Ninja `
    -DNOFORTRAN=ON `
    -DCMAKE_C_COMPILER=clang-cl `
    -DCMAKE_MAKE_PROGRAM="$NINJA" `
    -DBUILD_WITHOUT_LAPACK=0 `
    -DDYNAMIC_ARCH=1 `
    -DDYNAMIC_LIST="EXCAVATOR;HASWELL;ZEN;SKYLAKEX;COOPERLAKE;SAPPHIRERAPIDS" `
    -DBUILD_LAPACK_DEPRECATED=0 `
    -DBUILD_WITHOUT_CBLAS=1 `
    -DCMAKE_BUILD_TYPE=Release `
    -DCMAKE_INSTALL_PREFIX="$InstallDir" `
    -DBINARY=64 `
    -DUSE_THREAD=1 `
    -DNUM_THREADS=128 `
    -S ..

What did you do?

• Run a Go program that calls a C++ API, which in turn uses OpenBLAS's sgemm function for matrix multiplication. The C++ API calls sgemm in a loop, and the Go code calls the C++ API in a loop as well.

• The process works properly for some time. However, even after terminating the Go loop, there is a thread leak in the sgemm_ call, where one thread remains running without any apparent reason.

• Using -DUSE_THREAD=0 fixes this problem, but in our production environment, -DUSE_THREAD=0 is not feasible and must be -DUSE_THREAD=1. This issue only occurs on Windows and not on Linux.

[martin-frbg]

This is probably related to recent changes (from PR #4359) made to improve multithreading performance on Windows. Could you try if #4835 fixes this for you (I think it should apply cleanly to 0.3.26) ? Unfortunately it is still unclear if the PR itself was problematic, or if it uncovers a pre-existing failure in our level 3 BLAS threading code for Windows.

[CascadingRadium]

thanks for the reply.. seeing the history of this issue i see that

• https://github.com/OpenMathLib/OpenBLAS/pull/4359 introduced this issue in v0.3.26 (also seen in https://github.com/OpenMathLib/OpenBLAS/issues/4582)
• partial fix was in v0.3.27 (was giving wrong results in numpy)
• the PR (now merged) has really fixed the issue with the revert (slated for v0.3.28)

we have decided to just rollback to v0.3.25 and the windows prod pipeline is now passing ... thanks

[martin-frbg]

Thanks for the confirmation. I hope to release 0.3.28 tomorrow (or on the upcoming weekend at the very latest)