For data-race detection, Inspector XE will detect a data race if, during the particular run it monitors:
- It observes a pair of memory accesses from different threads to the same memory address
- At least one of which is a write
- And, it is not possible to determine the order of the memory accesses given the synchronization primitives that Inspector XE has observed the program call. The synchronization primitives that are "recognized" are described in the Supported APIs section of the product documentation.
For deadlock detection Inspector XE will detect a deadlock if, during the particular run it monitors:
- There is a deadlock involving 6 or fewer threads
- Where all of the threads involved in the deadlock are invoking mutex (or, on Windows, Critical Section) locking primitives
- And the calls they are using are not set to time-out (or the time-out is set to infinity). Again: the mutex locking calls they are using have to be on the list of Supported APIs.
In some modes, there are optimizations used that will cause Inspector XE to miss a data race (as defined above). They are:
- In Detect deadlocks mode, data races are not detected at all.
- In Detect data races and deadlocks mode, stack reads and writes are not monitored, so data races where one thread is accessing another's stack will be missed.
- In Detect data races and deadlocks mode, sometimes the first race to a particular memory location will be missed. (Monitoring a memory location does not start until it is known to be shared, so if the first shared access is also a race, it will not be reported as race.)
- In Locate data races and deadlocks mode with scope set to Normal, the same two optimizations that cause (2) and (3) exist. Setting scope to Extremely thorough will turn the optimizations off.