Community
cancel
Showing results for 
Search instead for 
Did you mean: 
AndrewC
New Contributor I
36 Views

Thread safety of MKL_DIRECT_CALL

The MKL_DIRECT_CALL macros expand to something like

if(.....){

.......

}else{

static MKL_INT mkl_direct_call_flag = 0

zgemm_direct((transa), (transb), (m), (n), (k), (alpha), (a), (lda), (b), (ldb), (beta), (c), (ldc), &mkl_direct_call_flag);

}

The  static variable is initialized the FIRST time the block is entered, so its not thread-safe.

0 Kudos
3 Replies
Murat_G_Intel
Employee
36 Views

Thank you for trying the new MKL_DIRECT_CALL feature! The static variable is always set to the same value within its scope (the value is determined at the compile time). Therefore, each thread should see the same value for mkl_direct_call_flag. However, we will look into this and evaluate alternatives to static MKL_INT. Perhaps we can just declare it as just an MKL_INT or as a const.

AndrewC
New Contributor I
36 Views

Using a static variable inside a "block" is a 'classic' way to cause a write data race. Unlike static variables at global scope which are initialized by _crtstartup ( or similar) the value of the static in a block is initialized during execution when the block is entered for the first time. Clearly this can cause a data race.

thread 1 enters the block , and begins the static initialization

thread 2 enters the block , maybe skips the initialization ( as thread 1 has set some flag) and calls zgemm_direct but the value of the static has not actually been set by thread 1 yet so will be arbitrary.

I am assuming the variable is static for some reason?

Obviously I could do something dirty like force a call to the matrix routines from the main thread at startup so this static gets initialized.

 


 

Murat_G_Intel
Employee
36 Views

The variable was declared as static because its value was expected to remain fixed for a compilation unit. I think we overlooked the thread safety issue. As you mentioned, we should probably change this declaration to regular int. Thank you very much again for the followup and letting us know the issue.

Reply