Project

General

Profile

Bug #901

Threads awoken by CthAwaken don't let Projections trace back to the event that woke them

Added by Phil Miller over 3 years ago. Updated over 1 year ago.

Status:
Merged
Priority:
Normal
Category:
-
Target version:
Start date:
11/30/2015
Due date:
% Done:

0%


Description

When working with code using threads (threaded entry methods, probably AMPI as well), Projections traces are somewhat annoying to work with in the timeline, because clicking on the bar representing the thread's execution produces the warning that "Message was sent from outside the current time range" which is very misleading. CthAwaken() should record the event that led to that thread being placed in the queue as runnable, so that awakenings can be traced back.

On close examination, there is a trace from the message event to the dummy_thread_chare::dummy_thread_ep event, but then none from that to the actual work that runs in the thread which gets recorded as a separate event.

This of course breaks critical path following as well.

0001-Bug-901-Added-tracing-for-thread-context-switch-even.patch View (6 KB) Phil Miller, 01/08/2016 02:13 PM

Makefile (573 Bytes) Phil Miller, 01/08/2016 03:04 PM

threadTest.C View (1.16 KB) Phil Miller, 01/08/2016 03:04 PM

threadTest.ci (176 Bytes) Phil Miller, 01/08/2016 03:04 PM


Related issues

Related to Charm++ - Bug #1430: CthThread tracing broken - threads show up as black, dummy_thread_chare assigned to following entry Merged 02/17/2017

History

#1 Updated by Phil Miller over 3 years ago

Patch implemented in collaboration with Charmworks prospective hire Steve Hoelle. Attached, will post to Gerrit shortly.

Cleans up tracing around thread creation/switching events substantially, gets me the tracing I need.

#2 Updated by Phil Miller over 3 years ago

Test case that we wrote and used to debug these various changes. To be meaningful to integrate in the automatic test suite, would need to add some introspection into what the traces are recording (i.e. whether each resumed thread depends on the event that awoke it).

#4 Updated by Sam White over 3 years ago

  • Target version changed from 6.7.1 to 6.8.0

The patch needs manual verification for BigSim

#5 Updated by Phil Miller over 2 years ago

  • translation missing: en.field_closed_date set to 2016-11-08 15:14:27.244315
  • Status changed from Implemented to Merged

#6 Updated by Jim Phillips over 2 years ago

This does not appear to work for threads as used in NAMD where threads are awoken from regular entries rather than other threads.

#7 Updated by Jim Phillips over 2 years ago

Also, threads are created by CthCreate(), not as [threaded] entries.

#8 Updated by Phil Miller over 2 years ago

Jim: Could you try things out with the above change reverted? Looking at the code again, I realize I may have actually broken the cases you mention while fixing the case I was concerned with.

#9 Updated by Jim Phillips over 2 years ago

With change 989 reverted I now see correct tracing for Cthreads.

#10 Updated by Phil Miller over 2 years ago

  • Related to Bug #1430: CthThread tracing broken - threads show up as black, dummy_thread_chare assigned to following entry added

#11 Updated by Phil Miller over 2 years ago

  • Status changed from Merged to In Progress

#12 Updated by Phil Miller over 2 years ago

  • Target version changed from 6.8.0 to 6.8.1

This isn't a regression relative to 6.7, and I'm not immediately able to get back to this. Deferring for now.

#13 Updated by Sam White about 2 years ago

With issue #901 resolved now, this issue has become a more visible sore of AMPI Projections usage. Note that AMPI threads are created by TCharm with a call to CthCreate(). AMPI does have a few [threaded] entry methods too, but those only used for split-phase communicator creation.

#14 Updated by Phil Miller almost 2 years ago

  • Target version changed from 6.8.1 to 6.9.0

#15 Updated by Seonmyeong Bak over 1 year ago

This issue is similar to the following CkLoop tracing issue and I fixed in my local branch for ULT OpenMP to be shown on Projections correctly.
https://charm.cs.illinois.edu/redmine/issues/1437

I'll push this patch when available.

#17 Updated by Sam White over 1 year ago

Seonmyeong, can you push this patch to gerrit?

#18 Updated by Seonmyeong Bak over 1 year ago

  • Status changed from In Progress to Implemented

#20 Updated by Phil Miller over 1 year ago

  • Status changed from Implemented to Merged

Also available in: Atom PDF