Threading Error Analysis Types

Intel® Inspector User Guide for Linux* OS

Download PDF

ID 767796

Date 5/15/2022

Version

Public

A newer version of this document is available. Customers should click here to go to the newest version.

Threading Error Analysis Types

Intel Inspector offers a range of preset threading analysis types to help you control analysis scope and cost:

Analysis types with the narrowest scope minimize the load on the system and the time and resources required to perform the analysis; however, they detect the narrowest set of errors and provide minimal details.
Analysis types with the widest scope maximize the load on the system and the time and resources required to perform the analysis; however, they detect the widest set of errors and provide context and the maximum amount of detail for those errors.

TIP:

Use analysis types iteratively. Start with a narrow scope to verify the application is set up correctly and set expectations for analysis duration. Widen the scope only if you need more answers and you can tolerate the increased cost.
Estimated collection time may be 2 to 320 times longer than normal application execution time.
Data set size and workload have a direct impact on application execution time and analysis speed.

Some settings in each preset analysis type are configurable. If the combination of settings in a preset analysis type almost meets your needs, try fine-tuning these configurable settings.

If the combination of analysis type settings in the preset analysis types does not meet your needs at all, try creating a new custom analysis type based on the currently selected analysis type.

Threading Error Configuration Settings for Each Preset Analysis Type

The following table shows the settings (in alphabetical order) for each preset analysis type:

N/A means not applicable for the preset analysis type (which means any value displayed in the GUI is greyed out)
Configurable means you can change the setting without creating a custom analysis type.
Renamed/split/combined configuration settings show previous manifestations.

Configuration Settings / Preset Threading Error Analysis Types	Detect Deadlocks (Narrow Scope)	Detect Deadlocks and Data Races	Locate Deadlocks and Data Races (Wide Scope)
Cross-thread stack access detection	Hide problems/Hide warnings	Hide problems/Show warnings	Hide problems/Show warnings if Scope=Normal, Hide problems/Hide warnings if Scope=Extremely thorough
Detect data races	No	Yes	Yes
Detect data races on stack (previously called Detect data races on stack accesses	N/A	No	No if Scope=Normal, Yes if Scope=Extremely thorough
Detect deadlocks (split from Detect lock hierarchy violations and deadlocks)	Yes	Yes	Yes
Detect lock hierarchy violations (split from Detect lock hierarchy violations and deadlocks)	Yes	Yes	Yes
Filter guaranteed atomics	N/A	No	No
Race analysis byte granularity (previously called Memory access byte granularity)	N/A	4 bytes	2 bytes if Scope=Normal, 1 byte if Scope=Extremely thorough
Remove duplicates	Yes	Yes	Yes (configurable)
Save stack on first access	N/A	No	Yes
Save stack on lock creation	Yes	Yes	Yes
Save stack on memory allocation (previously called Save stack on allocation)	N/A	No	Yes
Scope	N/A	N/A	Normal (configurable)
Stack frame depth	1 (configurable)	1 (configurable)	16 (configurable)
Terminate on deadlock	No (configurable)	No (configurable)	No (configurable)
Use maximum resources	No	No	No (configurable)

Threading Error Analysis Type Configuration Setting Descriptions

The following table describes the purpose, usefulness, and cost (low, medium, high, or proportional in terms of time and resources) for each analysis type configuration setting. (The settings are listed in alphabetical order.)

Setting	Purpose, Usefulness, and Cost
Cross-thread stack access detection	Use to set the alert mechanism for when a thread accesses stack memory of another thread. The alert mechanism helps you decide if this is an issue that requires handling. All options are low cost if Detect data races is selected. Recommendation: Use Hide problems/Hide warnings if using an OpenMP* or oneAPI Threading Building Blocks (oneTBB) programming model; or if cross-thread stack accesses are anticipated. Also select Detect races on stack. Use Hide problems/Show warnings if cross-thread stack accesses are not anticipated. Also deselect Detect data races on stack. Use Show problems/Hide warnings if cross-thread stack accesses are not anticipated but a previous analysis indicated they exist and you are not using an OpenMP* or oneAPI Threading Building Blocks (oneTBB) programming model. Also deselect Detect data races on stack.
Detect data races	Select to detect problems where multiple threads access the same memory location without proper synchronization and at least one access is a write. Selecting is useful when you suspect data races that are not yet evident. High cost. Recommendation: Select. Consider also deselecting Use maximum resources to reduce cost.
Detect data races on stack (previously called Detect data races on stack accesses)	Available only if Detect data races is selected. Select to detect data races for variables allocated on the stack. Selecting is useful when threads in an application share variables from the stack and you suspect data races on the variables. High cost. Recommendation: Deselect. If you select, consider also deselecting Use maximum resources to reduce cost.
Detect deadlocks	Select to detect problems where two or more threads are waiting for the other to release resources, but none of the threads releases the resources. Thus no thread can proceed. Selecting is useful when you want to troubleshoot the location of a deadlock. Low cost.
Detect lock hierarchy violations	Select to detect problems where the acquisition hierarchy order of multiple synchronization objects in one thread differs from the acquisition hierarchy order in another thread, and could cause a deadlock under certain conditions. Selecting is useful when an application has complicated synchronization and it is hard to verify correctness. Low cost unless an application has a significant number of locks.
Filter guaranteed atomics	Available only if Detect data races is selected. Select to ignore data races on guaranteed atomic operations on the Intel® P6 processor family or newer. For details, please refer to the Guaranteed Atomic Operations section of the Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A. Selecting is useful if you observe many false data race reports on simple operations like Load or Store to shared variables and the size of those variables is less than the processor cache line size. Do not select this option if you develop cross-platform code that should work on other architectures. Selecting this option might also hide true-races on variables that were properly aligned during this run but might not be aligned in general, e.g., if it just works “by chance”. Low cost. Recommendations: Use this option with caution only if you observe many false reports on simple memory operations.
Race analysis byte granularity (previously called Memory access byte granularity)	Available only if Detect data races is selected. Use to set the size of the smallest memory block the Intel Inspector considers a single block of memory when determining if non-synchronized accesses to a memory block constitute a data race. Selecting is useful to control memory consumption during analysis for some applications. High cost when set to 1 byte. Recommendation: Set to 4 unless you continually see data races based on safe access to smaller memory blocks. If so, reset to 1.
Remove duplicates	Deselect to show all occurrences of a detected problem in the Code Locations pane. Deselecting is: Useful when you need to fully visualize all threads and problem occurrences in relation to time Low cost in terms of time; however, the number of duplicate errors could crowd out the number of unique errors. Recommendation: Select.
Save stack on first access	Available only if Detect data races is selected. Select to show as much information as possible on all threads involved in a data race. Selecting is useful when investigating complex data race problems. High cost. Recommendation: Deselect on initial analysis runs. Select only when you need the maximum information and context about all threads involved in a data race to solve the problem.
Save stack on lock creation	Select to show creation information on synchronization objects involved in deadlocks, lock hierarchy violations, and data races. Selecting is useful when acquisition stacks are not sufficient to understand the problem. Low cost.
Save stack on memory allocation (previously called Save stack on allocation)	Available only if Detect data races is selected. Select to identify the allocation site of dynamically allocated memory objects involved in data races. Medium cost. Recommendation: Select when you need to identify the object hierarchy of low-level objects involved in data races. For example: If object R is involved in a data race and is instantiated within objects O1, O2, and O3, the allocation call stack can help you identify which encapsulating object is not properly protecting access to object R.
Stack frame depth	Use to provide more or less call stack context for detected errors. A high setting is useful when analyzing highly object-oriented applications. A higher number does not significantly impact cost with one exception: Choosing a higher number plus selecting Save stack on first access increases cost. Recommendation: Use only as large a value as an application requires to display complete call paths.
Terminate on deadlock	Available only if Detect deadlocks is selected. Select to stop analysis and application execution if the Intel Inspector detects a deadlock. Selecting is useful when running your application as part of a kernel or unit testing suite. Low cost. Recommendation: Deselect. Instead, use the corresponding knob in the command line interface to perform kernel or unit testing in a nightly scenario. If the Intel Inspector identifies a deadlock, decide if it is appropriate to continue analysis.
Use maximum resources	Select to potentially find more problems. High cost. Recommendation: Deselect to run a quicker analysis that should find most of your data race and cross-thread stack access problems. Once you have found and fixed these problems, select to get more complete analysis coverage of possible data race and cross-thread stack access problems.

Parent topic: Configuring Analyses

Select Your Language

Using Intel.com Search

Quick Links

Recent Searches

Advanced Search

Only search in

Intel® Inspector User Guide for Linux* OS

Threading Error Analysis Types

Threading Error Configuration Settings for Each Preset Analysis Type

Threading Error Analysis Type Configuration Setting Descriptions

See Also