Expected: 49999995000000 But was: 49999995032768

[Matt Davey]

Its not uncommon to see the following assertion. Based in early
investigation, "32768" appears to be the YieldStrategy.WaitFor return
this the first time in certain scenario's - possibly due to an
ordering issue with consumer/produce starting in a certain way. Hence
investigation is needed :)

Exception thrown in
UniCast1P1CPerfTest:NUnit.Framework.AssertionException: R
nDisruptorPass
Expected: 49999995000000
But was: 49999995032768

at NUnit.Framework.Assert.That(Object actual, IResolveConstraint
expression,
String message, Object[] args)
at NUnit.Framework.Assert.AreEqual(Int64 expected, Int64 actual,
String mess
ge)
at Disruptor.PerfTests.UniCast1P1CPerfTest.RunDisruptorPass(Int32
passNumber
in C:\dev\googlecode\disruptor-net\Source\Disruptor.PerfTests
\UniCast1P1CPerfT
st.cs:line 167
at
Disruptor.PerfTests.AbstractPerfTestQueueVsDisruptorVsTplDataflow.TestImp
ementations() in C:\dev\googlecode\disruptor-net\Source
\Disruptor.PerfTests\Abs
ractPerfTestQueueVsDisruptorVsTplDataflow.cs:line 21
at
Disruptor.PerfTests.UniCast1P1CPerfTest.ShouldCompareDisruptorVsQueues()
n C:\dev\googlecode\disruptor-net\Source\Disruptor.PerfTests
\UniCast1P1CPerfTes
.cs:line 114
at
Disruptor.PerfTestRunner.Program.RunTest(AbstractPerfTestQueueVsDisruptor
sTplDataflow test) in C:\dev\googlecode\disruptor-net\Source
\Disruptor.PerfTest
unner\Program.cs:line 39

[Olivier Deheurles]

With current trunk or a previous version? 32 bits or 64 OS?

This is tipically the king of error I got when using non atomic
operations.

[Matt Davey]

Current trunk, OS 32 bits, put a break point on BatchConsumer.cs line
102 "var availableSequence = _consumerBarrier.WaitFor(nextSequence);"
and step into the function.

[Tim Gebhardt]

I did a binary search on the revisions and noticed it came on the revision where Java SVNr 211 was ported to our project.  This is SVNr 47.

Looking at the Java project it looks like they resolved an issue in 2 commits (211 and 212) and the second part we haven't ported over yet.

This could be the result of the off-by-one error.  The actual result is slightly off perhaps because one of the entries aren't being processed.


Tim

[Olivier Deheurles]

I know, r212 is in the backlog, I did not had time to port it yet.

I'm reviewing the latest revisions, give me 10 minutes ;)

[Matt Davey]

I think we need to support 32 and 64 bit, since that is what the Java
version does, and I believe Olivier is on 32 bit, and I am on 64 bit
and 32bit depending on which machine I am on :)

[Olivier Deheurles]

Matt, Tim

I just published a review on your revisions, could you have a look? ;)

First time I use the review feature in google code, have you tried it?
pretty good ;)

We should do reviews on every revisions, what do you think?

[Olivier]

I fixed the bug, the perf test run on my PC (64 bits). Tim could you
try to reproduce it with a unit test? We need to have better coverage,
this one should have been catched.

Matt have a look to my comments on the review, if there is still a
problem on 32 bits I think applying the requested changes should fix
the problem.

[Olivier]

I'm going to port it now...

[Olivier]

done

Review please ;)

[Chrisa23]

change to Disruptor project has a missing file, doesn't compile:

<Compile Include="Disruptor.cs" />

[Chrisa23]

LOL... nvm and I thought I double checked first...

On Jul 6, 8:25 pm, Olivier <m...@odeheurles.com> wrote:

[Tim Gebhardt]

Just resolved your comments on my check in.  See SVNr 62-63.

One thing is that the existing unit tests should have actually caught the error.  However, Moq was swallowing the exception thrown that would have indicated the error.  It's funny though that the exception and stack trace is printed to the console, it's just that the test passes as if nothing bad happened.

I like the review stuff on Google Code.  Seems pretty productive and low energy for the reviewer.


Tim