Needless to say (for the nth time :-) ) that changing this bit of code
nervous. However, it occurred to me that there is a much better way to
this code than setting up an environment that generates some out of order
events with out us being able to specify the order.
Since this routine is executed serially, it should be sufficient to set up
code that would simulate any out-of-order scenario we want. If one
number of ³messages² to be ³sent², and ³randomly² changes the order they
arrive (e.g. scramble some input vector), one can check and see if the
are ³received² in the correct order. One could even ³drop² messages and
if matching stops. Using a test code like this, and a code coverage tool,
should be able to get much better testing that we have to date.
What would you think about doing something like this ? Seems like a few
of this sort of simulation would be much better than even years of testing
relying on random fluctuations in the run to thoroughly test out-of-order
What do you think ?
On 12/17/07 8:32 AM, "Gleb Natapov" <glebn_at_[hidden]> wrote:
> On Thu, Dec 13, 2007 at 08:04:21PM -0500, Richard Graham wrote:
>> > Yes, should be a bit more clear. Need an independent way to verify that
>> > data is matched
>> > in the correct order sending this information as payload is one way to
>> > this. So,
>> > sending unique data in every message, and making sure that it arrives in
>> > the user buffers
>> > in the expected order is a way to do this.
> Did that. Encoded sequence number in a payload and sent many eager
> packets from one rank to another. Many packets were reoredered, but
> application received everything in a correct order.
> devel mailing list