Thread Inspector wish list to work issues as the one here described

[Salvatore_Li_Mandri]

I am trying to make some sense of what is going on while the Thread Inspector runs and match the events been reported with a Log Text file that appears in a window of an application I am writing which must be fault tollerant.

I have been able to test this way and run stand alone to up to 8 cores with no known issues in a controlled environment used for testing.

I had to to this, since the Inspector allows no concurrent debugging with breakpoints insert by the IDE and any ASSERT inserted in the code is of little or limited help if I do not see the whole context the thread is running as

If the tested code ASSERTs, it shows the module and the line number in the Dialog Box - (thanks)

If I say RETRY, hoping I get to see the code and the context, nothing happens (that I can tell)

Each of the threads in the application I am testing are part of a pool of standard threads I created that must finish in a certain amount of time for critical reasons. They are supervised by a thread which must receive an event signaling completion in a certain ammount of time.

If one of them does not, it will be considered as lost somewhere processing some bad data and it will be deleted and recreated on the fly again.

The application tolerates the fact that a data frame is not processed and it will capture the frame for futher debugging.

Due to the presence of the Inspector, there is no way to tell how much degradation in performance it will supply (ow long to wait for the Event to arrive).

Because of this, the timeout value of normally 10 mSec was changed to be 1500 mSec for each thread

I believe I still get false positive, but to confirm I need some help...

I have a supervisor thread that monitor for the completion of any working thread (waiting for an Event inside a Time limit)

Each of these threads has its own memory and exclusive memory area

1: After the Inspector Run is completed, and the View switch to Problem Set + Data Race, is there a way to view again the original Event Log visible at runtime ? It is not obvious to me

2: The Event Log, while in operation, shows where the thread are created in one of the column.

To correlate with any home diagnostics I am forced to use emitted by the threads and my code, it would be nice to see somewhere a reference to the Thread ID - Is this a major big deal to add to future upgrades ?

It might be useful to others as well

3: Is there a RunTime symbol I could use to notice that I am running the application using the Inspector and so do automatically some internal application adjustments to conpensate for the extra time in execution is required ?

4: Is the behivior of the ASSERT + RETRY combination I described correct ?

5: Any idea if the Inspector will ever interface with the debugger and automatically break on command at first Race Condition to examine the context that procuce the Race, as future code operation and feature improvement (though the operation might be different of what I described) ?

Forgot to mention that this is an old application that uses standard threads (no OpenMP)

Thanks

[David_A_Intel1]

I assume you are referring to the Intel Parallel Inspector. Here is my attempt at some answers:

1: After the Inspector Run is completed, and the View switch to Problem Set + Data Race, is there a way to view again the original Event Log visible at runtime ? It is not obvious to me

No, there is not. Why do you want to? Seriously, I want to understand how you would use that display. It is just a chronological list of the problems that is displayed in a more organized fashion in the Problem Set view.

2: The Event Log, while in operation, shows where the thread are created in one of the column.

To correlate with any home diagnostics I am forced to use emitted by the threads and my code, it would be nice to see somewhere a reference to the Thread ID - Is this a major big deal to add to future upgrades ?

It might be useful to others as well

Seems reasonable. I will submit a feature request.

3: Is there a RunTime symbol I could use to notice that I am running the application using the Inspector and so do automatically some internal application adjustments to conpensate for the extra time in execution is required ?

Apparently, not. One suggestion would be to pass a parameter via your app's command line, so that when you launch it under the Parallel Inspector, you configure the parameter so that you app can check it and determine that it is being instrumented. Also, I would recommend NOT performing the timing checks when it is being checked by the Parallel Inspector. Performance testing should be a separate step of your development.

4: Is the behavior of the ASSERT + RETRY combination I described correct ?

Sorry, dunno.

5: Any idea if the Inspector will ever interface with the debugger and automatically break on command at first Race Condition to examine the context that procuce the Race, as future code operation and feature improvement (though the operation might be different of what I described) ?

This is a request we have heard/seen before. It is definitely something we are considering, but I have no announcement to make about when you might see it.

[Salvatore_Li_Mandri]

Hi, and thanks for the reply...

The reason I was interested to see the EventLog in Q1 was so I can study the order of creation forthe dynamic thread I create on the fly and if their order produced anything of un-usual been reported later on by the tool - Obviously this would have some use only if the THREAD ID was also reported next to the Creation Message description, so I could connect those messages to my TRACE message which appear in a temporarywindow.

What I just said is probably a crude way to say that I wish I could write into the same EventLog my own Compiler TRACE messages that at this time are been ignored by the Thread Inspector all together.

The ASSERT I get at times, appears only when I run with the Inspector and since I cannot start another debug session on that (I believe) or see my TRACE messages I have been guessing for a little while

I thought this feature could make the tool more friendly

Thanks

Sal