Inquiry and Suggestions Regarding OpenBLAS Code Flow with OpenMP

Bắt đầu bằng cách lần theo gemm_driver trong driver/level3/level3_thread.c và exec_blas cùng inner_thread trong driver/others/blas_server_omp.c. Tái hiện deadlock đã được báo cáo với số lượng thread OpenMP ít hơn số phân vùng của hàng đợi, sau đó so sánh các luồng xử lý locking và busy-waiting. Công việc được xem là hoàn tất khi có một giải thích đã được xác nhận và một thay đổi về đồng bộ hóa với phạm vi được xác định rõ ràng hoặc một kết quả về tài liệu.

Hello,

I've been delving into the OpenBLAS codebase, specifically focusing on the gemm_driver function in level3_thread.c with the #USE_OPENMP=1 flag enabled. I've come across a section in the code where a lock is used in the Pthreads and Win32 backend before initializing and assigning the blasqueue. The lock is released only after the exec_blas call is completed.

My current understanding is :

1. In the case of Pthreads The thread pool is initialized (POSIX), and when a BLAS call is made, the thread pool is utilized to execute it, after which the threads go back to sleep. The use of locks ensures that only one exec_blas call can be executed at a time.

2. If I use a thread pool with No_of_threads < nthreads (number of queue partitions) defined in level3_thread.c, I encounter a deadlock within the inner_threads function.
3. There seems to be significant busy-waiting (NOP) inside the inner_thread function call for thread synchronization.

I have a few questions and want to seek suggestions from the community:

1. I noticed that OpenMP locking mechanisms like omp_set_lock are not used, and instead, busy-waiting is implemented inside the exec_blas function in blas_server_omp.c using max_parallel_number. Could you please provide insights into this choice?

2. The inner_thread function appears to encounter deadlock when used with fewer threads. I tested this in OpenMP by creating a parallel region inside exec_blas in line 437 - blas_server_omp.c with a fixed number of threads less than nthreads. Could you shed some light on the reasons behind this behavior?

3. Considering the busy-waiting in the code, have there been considerations for putting threads to sleep or employing other synchronization methods to enhance efficiency?

I would appreciate clarification on these points.