Project

General

Profile

Bug #53

SDAG case constructs and Bigsim traces

Added by Phil Miller over 6 years ago. Updated almost 2 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
02/18/2013
Due date:
% Done:

0%


Description

Inspired by some other discussion, I went to look at the implementation of SDAG case clauses to see how they'd interact with Bigsim emulator trace recording. It looks like the natural result they'll produce is a dependence of the when that gets satisfied on the incoming messages that satisfied it and the preceding event, as it should be. This is perfect in the purely non-speculative case, where no messages that might match other whens in the case ever appear.

In the speculative case, I'm concerned that some messages might be improperly associated to multi-entry whens that never end up getting satisfied. I could picture this producing misleading traces or broken traces, or even crashing the runtime, though I'm uncertain which without further examination. We should try this and make sure that we haven't broken the bit of Bigsim that depends on SDAG.

History

#1 Updated by Phil Miller over 6 years ago

  • Target version set to 6.6.0

#2 Updated by Phil Miller over 5 years ago

  • Target version changed from 6.6.0 to 6.7.0

#3 Updated by Nikhil Jain over 4 years ago

Bilge and I were working on BigSim recently and found that sdag + bigsim emulation does not work for simple cases too. At the least, I wish to find the reason. Jonathan may already know?

#4 Updated by Eric Bohm over 4 years ago

  • Assignee changed from Jonathan Lifflander to Eric Mikida

#5 Updated by Phil Miller almost 4 years ago

  • Target version changed from 6.7.0 to 6.8.0

Nikhil notes that we're not generally using Charm code to generate these traces, and there are other issues if we want to do that. Not important for production, only for research. Thus, postpone.

#6 Updated by Eric Bohm almost 3 years ago

Its been a year since the last update. If this is important someone should start work. If it isn't, the priority should be changed to low.

#7 Updated by Sam White over 2 years ago

  • Target version changed from 6.8.0 to 6.8.1
  • Priority changed from Normal to Low
  • Assignee deleted (Eric Mikida)

#8 Updated by Eric Bohm almost 2 years ago

  • Target version changed from 6.8.1 to 6.9.0

#9 Updated by Phil Miller almost 2 years ago

  • Target version deleted (6.9.0)

Also available in: Atom PDF