Disruptor-net 1.0

[Olivier]

Version 1.0 has been released and is available from the download
section.

Changes:
- New API to configure the disruptor (look at the performance tests
to see some samples)
- Removed value type ring buffer
- Improved significantly the perf test runner (better reporting,
adjusted duration of tests, print additional system informations,
print warnings if insuficient cores or HT is turned on)

Feedback welcome ;)

Olivier

[Fil Mackay]

> Changes:

>  - Removed value type ring buffer

How come this was removed?

Regards, Fil.

[Olivier Deheurles]

Hi Fil,

I've been playing with the value type ring buffer and I realized there was a major downside compared to the reference type version: as soon as you implement a real world scenario where you have multiple steps (something like the diamond sample or the 3 step pipeline), the first consumers (event processors I should say) need to do some processing and often mutate the state of the event.

Let's take the example of LMAX architecture:
- event processor "unmarshaler" deserialise some binary data
- the resulting object is 'attached' to the event
- the business logic event processor then uses the deserialised object

Now imagine you want to do the same thing but this time the event is a struct:
- producer thread creates the struct and commit to the ring buffer
- unmarshaler gets a copy of the event (value type = copy semantic). Unmarshaler can not attach the deserialised object to the event, it only owns a copy... We would have to commit back the whole event to the ring buffer.

2 downsides:
- performance: commiting back the whole struct invalidates all the cache lines containing it
- complexity: the producer side and the consumer side ends up with completly different semantics compared to the reference type version, which means 2 different implementations of most classes of the disruptor. Developer would as well have to use 2 different APIs which is not great...

I may put it back at some point if I come up with a better design, but I'm not sure it will be possible.

Olivier

[Fil Mackay]

Thanks for the reply!

So you want to share side-effects between consumers? I thought if you
wanted to do that (note: I have no real-world Disruptor experience
yet, so be patient :) you would do:

P1 -> C1-(attach, make changes etc.)-P2 -> C2

The above would work fine with no side-effect sharing?

I didn't know that consumers could process in a specific order, and
thereby share side-effects?

Regards, Fil.