aeron/agrona xadd based log buffer

[ymo]

Hi All

I just had a blast listening to https://goo.gl/ueLoZX (around 24:47) Now i was wondering:

1) Is this in agrona/aeron already and where ? [1] seems to not be based on xadd.

2) Can you create and infinite (albeit distributed among many  file/buffers) ManyToMany Log buffer. I Imagine that there is nothing stopping this buffer from being a ManytoMany instead of a ManytoOne ? 

3) If you have 3 threads A (3) ,B (2) ,C (1) coming to claim the capacity in that order and C succeeds B trips on the padding/end . Does A have to spin to wait for B to setup the new buffer ? How does A figure to use the new buffer created/pointed by B ?

[1]:https://github.com/real-logic/Agrona/blob/master/src/main/java/uk/co/real_logic/agrona/concurrent/ringbuffer/ManyToOneRingBuffer.java

Regards

[Martin Thompson]

On 18 February 2016 at 11:09, ymo <ymol...@gmail.com> wrote:

1) Is this in agrona/aeron already and where ? [1] seems to not be based on xadd.

The Agrona collections you have been looking at are the existing CAS based approaches. The new approach I mentioned in this video can be found in this entry point:

https://github.com/real-logic/Aeron/blob/master/aeron-client/src/main/java/uk/co/real_logic/aeron/Publication.java

Which calls into the following where the XADD is employed.

https://github.com/real-logic/Aeron/blob/master/aeron-client/src/main/java/uk/co/real_logic/aeron/logbuffer/TermAppender.java

 

2) Can you create and infinite (albeit distributed among many  file/buffers) ManyToMany Log buffer. I Imagine that there is nothing stopping this buffer from being a ManytoMany instead of a ManytoOne ? 

Aeron is designed for many producers to many consumers where each consumer sees all the messages in a multicast fashion. You could build a queue on top of it but that is not the current use case.

 

3) If you have 3 threads A (3) ,B (2) ,C (1) coming to claim the capacity in that order and C succeeds B trips on the padding/end . Does A have to spin to wait for B to setup the new buffer ? How does A figure to use the new buffer created/pointed by B ?

When a log is tripped a new buffer does not need to be allocated. Three buffers are used in a round robin fashion. The trip is just a change of index via an ordered write. The buffer is zero'ed and readied for use by background thread in advance of it being needed. You can follow the algorithm from the Publication class I referenced above.

 

[ymo]

Thanks a lot Martin ... exactly what i needed !

I have more questions if can please you explain )))

1) in [1] what's the point of aligning the memory ?

2) Is the Aeron term appender log supposed to be consumed by a single core per log to be cache optimized ? if all message types in the buffer are handled by any core then i will introduce branch mis-predction since the first thing i have to do for each message is check what type of message it is before handling it. If i decide to handle one message type per core i will not be cache optimized since the cpu will keep jumping ahead in memory. Or Is the idea to create one log per message type then and process them all in batches from a single core at a time ?

3) Why is zeroing the non active buffer important if each block is overwriting the previously stored data with new framed based blocks ?

[1] https://github.com/real-logic/Aeron/blob/master/aeron-client/src/main/java/uk/co/real_logic/aeron/logbuffer/TermAppender.java#L135

[Martin Thompson]

On 20 February 2016 at 02:52, ymo <ymol...@gmail.com> wrote:

1) in [1] what's the point of aligning the memory ?

Depending on CPU microarchitecture, if you address memory when not on a boundary divisible by the length of the type then effects range from reduced performance through to processor exceptions. This is especially important for atomic operations.

 

2) Is the Aeron term appender log supposed to be consumed by a single core per log to be cache optimized ? if all message types in the buffer are handled by any core then i will introduce branch mis-predction since the first thing i have to do for each message is check what type of message it is before handling it. If i decide to handle one message type per core i will not be cache optimized since the cpu will keep jumping ahead in memory. Or Is the idea to create one log per message type then and process them all in batches from a single core at a time ?

The TermAppender is designed to be concurrent for use across threads as the *producer*. I'm not sure were your question is coming from about consumption.

If what you mean is the consuming side, which is Subscription/Image/TermReader stack, then yes you can have different types of messages in the buffer which can be discriminate on a type id which would could be added. The possible mis-predication here is minuscule compared to the cost of data exchange across cores, sockets, or even servers. This is normal demuxing. The much more significant cause of speculation and mis-prediction is the lack of access to the x86 PAUSE instruction from current Java when doing spin-wait loops. In future this may be addressed by http://article.gmane.org/gmane.comp.java.openjdk.hotspot.compiler.devel/20974