Thread safety of MKL_DIRECT_CALL

[AndrewC]

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.

[Murat_G_Intel]

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]

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]

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.