8/6/2019 Multicore Simulator
1/24
Submitted To :
Submitted By :
8/6/2019 Multicore Simulator
2/24
Intel(R) Thread Checker is a threading correctness toolthat can detect races,deadlocks,stalls,threading APIusage violations, as well as memory overwrites andleaks in your software.
Use the Intel(R) Thread Checker to locate bugs in yourmulti-threaded programs. Thread Checker identifiesdiagnostics by finding places where the behavior of yourprogram in a multi-threaded environment is potentiallynon-deterministic.
Multiple threads can create a situation where the same
memory location (variable) could be accessed at the sametime by more than one thread.
While it is quite unlikely that these two accesses will occurat exactly the same time, it may be very likely that theorder in which the two accesses occur is not guaranteed bythe program.
8/6/2019 Multicore Simulator
3/24
This type of situation creates a "data race", which can
cause results to be indeterminate or to differ from the
output the serial version of the program produces.
In other cases a program or a subset of threads may in fact
not be able to continue executing at all because of errorsin the way it was programmed. This situation, called a
deadlock, arises when every thread in the group is blocked
from proceeding because it is waiting to acquire access to
a resource that is already held by some other thread in the
group.
Thread Checker identifies the following diagnostics and
potential issues such as:
Data races
Deadlocks
8/6/2019 Multicore Simulator
4/24
stalled threads
lost signals
abandoned locks
After running your program with Thread Checker to collectdata, use Thread Checker to view the results of your
program's execution and display a prioritized list of
diagnostic and warning messages. You can sort and
organize the Diagnostics list in various ways to help you
focus on the most important issues first.
Thread Checker supports analysis of threaded programsthat use OpenMP*, POSIX*, and Windows* API.
8/6/2019 Multicore Simulator
5/24
In order to find out where your program is incorrect, theIntel(R) Thread Checker modifies your program by insertingcalls to a library that records information and analyzes theexecution of your program. Analysis includes inspection of:
all memory accesses
all synchronization operations
all thread creation operations
o The task of examining the memory access patterns of yourprogram during your program's execution is referred to as the"Analysis" step. You can control how analysis is performed
though various configuration options.o The actual task of doing this analysis is performed by the
Intel(R) Thread Checker Runtime Engine which is linkedinto your application.
8/6/2019 Multicore Simulator
6/24
Thread Checker does an execution-driven simulation of
your application. It finds diagnostics only in code that is
executed. For example, if a loop is executed through only
one iteration, it will not find any issues where a
dependence exists from one iteration to the next. For each memory location accessed by the application,
Thread Checker maintains information about the logical
time at which the access occurred, and information about
which thread caused each access. Thread Checker also
tracks the application's use of API functions related to the
management of threads and the synchronization between
threads.
Thread Checker uses two main approaches to detect
diagnostics:
8/6/2019 Multicore Simulator
7/24
It uses the information about memory accesses to
determine if a data-race is present. As a by-product of
the work needed to determine data-races, Thread
Checker also evaluates memory accesses to determine if
the access was to memory that was not initialized, orwas to out-of-bounds memory that was not allocated by
your application.
It investigates resource usage to detect thread
interaction diagnostics. These diagnostics are typically
synchronization resource conflicts: for example,
deadlocks, potential deadlocks, and stalls. Each of these
diagnostics is reported as a sequence of pair-wise
resource conflicts where two threads are attempting to
use the same resource in a potentially unsafe or non-
deterministic manner.
8/6/2019 Multicore Simulator
8/24
When using the Thread Checker to check memoryaccesses, your application uses significantly more systemmemory and time when executing. It is not uncommon forthe memory to grow to twenty times the original memoryrequirements and for the execution time (CPU use) to
increase to more than 300 times the original executiontime
Thread Checker cannot guarantee it will find and report alldata races that exist. Thread Checker's analysiscompensates for much of the non-deterministic nature ofthreaded programs but the potential for some non-deterministic results remains. Also, multiple accesses tothe same memory location may result in the reporting ofonly one race on that location even when more than onerace exists, because of performance considerations in theanalysis.
8/6/2019 Multicore Simulator
9/24
Data races occur when multiple threads simultaneouslyaccess shared variables, which can corrupt data and giveunexpected results. Because threads are scheduled in anon-deterministic manner, data races are not alwaysapparent. The most common cause of data races is
assuming a specific execution order between threads whenin fact the execution order is uncertain.
Many factors can affect the order in which threads areexecuted, including processor speed, memory size, systemload, and operating system version. Changes in any ofthese factors can hide errors or reveal new ones. Theserelationships make data race errors difficult to find.
The Data Races sample code creates four threads, each ofwhich increments a single shared variable. Use IntelThread Checker to find a typical type of data race in thecode
8/6/2019 Multicore Simulator
10/24
Deadlocks occur when a thread must wait for a resource that itcannever acquire. Bad locking hierarchies are a common cause of
deadlocks.
A mutex is a synchronization object used to allow multiple
threads to serialize their access to a shared resource. The name
derives from the capability it provides: mutual exclusion. The
thread that locked a mutex becomes its owner and remains theowner until that same thread unlocks the mutex. The example
program in this section uses the Windows* CRITICAL_SECTION
variable to enforce mutual exclusion.
The following example, though contrived, illustrates how an
incorrect locking hierarchy can cause deadlock. The two threadscreated in this program acquire two CRITICAL_SECTION variables
in reverse order. If both threads obtain only the first
CRITICAL_SECTION, deadlock results because the second
CRITICAL_SECTION never becomes available. It is possible for one
thread to acquire both CRITICAL_SECTION variables and avoid
deadlock. However, multithreaded programs that depend on aparticular order of execution are likely to fail.
8/6/2019 Multicore Simulator
11/24
Build the Deadlock sample located by defaultin \tcheck\Samples\Deadlock using the
compiler of your choice.
8/6/2019 Multicore Simulator
12/24
In Thread Checker, do the following:
5. Create a new Activity: right-click in the Tuning Browserand select New Activity.
6. Complete the IntelThread Checker Wizard for theDeadlock.exe debug image you created.
By default, Thread Checker forces termination of programsupon deadlock or program exit. You can change this setting
under Configure > Options > IntelThread Checker >Collector by deselecting the checkbox, Forcefullyterminate the program upon deadlock or program exit.
8/6/2019 Multicore Simulator
13/24
8/6/2019 Multicore Simulator
14/24
The Diagnostics list shown in Figure 7 indicates severalpotential deadlocks, since synchronization objects wereacquired in the wrong order. In addition to the Read->Write data race errors, Thread Checker diagnosed fourdeadlock errors indicating a potential deadlock due tobad locking hierarchy
8/6/2019 Multicore Simulator
15/24
Diagnostic list for Deadlock.exe example
8/6/2019 Multicore Simulator
16/24
To find the source location of the first deadlock error,
double-click the deadlock error at ID 3 to select it andopen the corresponding Source View location.
8/6/2019 Multicore Simulator
17/24
Source view showing the location of a potential deadlock
8/6/2019 Multicore Simulator
18/24
The 1st Access and 2nd Access panes of Source Viewshow the location of a potential deadlock because of alocking hierarchy in function work0. The easiest way toavoid deadlock when using locking hierarchies is to besure to always lock and unlock the CRITICAL_SECTIONs
in the same order for all threads. So, in this example,both work0() and work1() should first callEnterCriticalSection(&cs0) then callEnterCriticalSection(&cs1). This means that boththreads should call LeaveCriticalSection(&cs1) first andthen call LeaveCriticalSection(&cs0).
The Read -> Write data races occur because thevariables being updated are not consistently protected .
TIP:
To avoid deadlocks when using locking hierarchies, alwayslock and unlock critical sections in the same order for all
threads.
8/6/2019 Multicore Simulator
19/24
1. Start VTune Performance Analyzer and select"New Project"
2. From the Category drop-down menu
select Threading Wizards, then select the IntelThread Checker Wizard.
3. Locate the application you compiled by usingthe browse "..." botton and then click Finish to
start Thread Checker.
4. Depending on whether you experienceddeadlock or not, you will see the following or theother diagnostic list.
8/6/2019 Multicore Simulator
20/24
8/6/2019 Multicore Simulator
21/24
5. You might not face deadlock, but note that Intel Thread Checker
still catches it as a potential deadlock and it is lisited with yellow
bullets.
8/6/2019 Multicore Simulator
22/24
6. Also note the Read -> Write data-race
detected by the Thread Checker.
Read -> Write data-race happens when one thread reads a variable that is
subsequently updated by other thread
8/6/2019 Multicore Simulator
23/24
7. Double-click on one or more of the deadlock diagnostics
(error or warning) in the Diagnostics window. Explore whatlines Thread Checker points out as being involved in the
deadlock diagnostics.
8/6/2019 Multicore Simulator
24/24
1. Return to Microsoft Visial Studio to correct the program.
Q: Which portion of the code is causing the deadlock? A:Notice the order of the CRITICAL_SECTION objects cs0 andcs1 are used in each thread function work0() and work1().
2. From Microsoft Visual Studio, edit the program and re-build it.
3. When you have changed the source code, select BuildSolution from the Build menu to rebuild.
4. In the VTune analyzer environment, clickthe Activity menu and select Run to runIntel ThreadChecker again to validate that you have corrected all thethreading errors.