Charm++ parallel programming system

[Robert Steinke <rsteinke AT uwyo.edu>]

I have a question about using iteration numbers with structured dagger.  
I have an application where I send out a message with a value, and then 
either send or receive another message with an updated value.  It's 
possible for a chare to receive the second message before the first.  If 
that happens, it can ignore the first message.

I'm using iteration numbers, and it's even possible to receive the 
second message and go on to the next iteration before receiving the 
first message.  If that happens, I'll never receive the first message 
because I won't have a when statement waiting on that iteration number.  
It's not a problem within the application.  I don't need the information 
in that message.  But will that eternally unreceived message clog up the 
charm++ message buffers slowing things down and consuming memory?

Here's a concrete example:

while (true)
{
  serial { thisProxy[neighbor].sendState(iter, myState); }

  case
  {
    when sendState[iter](int i, StateType neighborState)
    {
      serial
      {
        // From my state and my neighbor's state I can figure out
        // if I need to send or receive an update message.
        if (send) { thisProxy[neighbor].sendUpdate(iter, update); iter++;}
      }
    }

    when sendUpdate[iter](int i, UpdateType update)
    {
      serial
      {
        // Do processing.
        iter++;
      }
    }
  }
}

I'd like to have a statement like this:

when sendState[iter > i](int i, StateType neighborState)
{
  // Ignore this old unneeded message.
}

But it looks like structured dagger only tests the iteration number for 
equality.  Is there any way to receive and ignore these old messages 
within structured dagger?  is there another way to clear them out of the 
message buffer?

If there isn't any way currently, it seems like it wouldn't be hard to 
implement having the iteration condition be an arbitrary boolean 
expression and if you want to test equality you just do [iter == i].  
The problem would be that it wouldn't be backwards compatible with the 
current semantics.

Thanks,
Bob Steinke