Multicore Simulator

8/6/2019 Multicore Simulator

1/24

Submitted To :

Submitted By :


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.


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


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.


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.


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:


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/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.


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


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.


11/24

Build the Deadlock sample located by defaultin \tcheck\Samples\Deadlock using the

compiler of your choice.


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.


13/24


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


15/24

Diagnostic list for Deadlock.exe example


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.


17/24

Source view showing the location of a potential deadlock


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.


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.


20/24


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.


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


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.


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.

Documents

Multicore Simulator