Is a Cross-thread Stack Access a Race Condition?

When you thread check your application at levels 2 ("Detect Deadlocks and Data Races") or 3 ("Locate Deadlocks and Data Races"), Intel® Inspector XE may report a "cross-thread stack access".  Some users are confused by this warning and this article is an attempt to more fully describe the detected condition.


First, this warning it is not a data race and cross-thread stack accesses (CTSA) are always reported regardless of any locking employed by your code. All CTSA says is that "thread A touched the stack of thread B."  There is no race implied nor is an error implied by CTSA. It is just a warning.

CTSA is meant to alert you to the fact that multiple threads are sharing the stack, in case it was unintentional.  CTSA also warns you that accessing another thread's stack may be unsafe, if not synchronized properly.

A mutex is not sufficient to guarantee safety. It can guarantee race safety but it can't guarantee that the stack variable still “exists” at the time of access (ie. the owner may have continued execution and popped the frame off of its stack).

The example from the help documentation may help to visualize the condition:

int *p; // global variable
CreateThread(..., thread #1, ...);
CreateThread(..., thread #2, ...); 

Thread #1:
    int q[1024]; // Allocated on Thread #1's stack
    p = q;
    q[0] = 1;
Thread #2:
    *p = 2; // Thread #1's stack accessed

If thread #1 and thread #2 are concurrent and there is no other synchronization between thread #1 and thread #2, the Intel Inspector XE detects a Cross-thread stack access problem if 'p = q;' in thread #1 executes before '*p = 2;' executes in thread #2 .

The example shows the case where thread #1 publishes the address of a local stack variable q to the global pointer p, and later thread #2 accesses the stack of thread #1 by dereferencing the global pointer p, in effect writing to the variable q on thread #1.

Detecting Cross Stack Accesses

You can create a custom analysis type and enable Detect data races on stack accesses.  See the product documentation for details on creating custom analysis types.  Once you have requested the custom analysis type, check the "Detect data races on stack accesses" to locate where the CSTA's are occuring.


Note: adding this detection will increase the overhead of the analysis.

You may also want to set the Cross-thread stack access detection to Show problems/Hide warnings so that the detected problems appear in the Summary tab but a warning is not displayed on the Collection Log tab.

For more complete information about compiler optimizations, see our Optimization Notice.