An asynchronous lock free ring buffer for logging

[giscus[bot]]

An asynchronous lock free ring buffer for logging

In this blog post, I showcase a very simple lock-free ring buffer for logging. I'll show why it's useful and how it works.

https://steven-giesel.com/blogPost/11f0ded8-7119-4cfc-b7cf-317ff73fb671/an-asynchronous-lock-free-ring-buffer-for-logging

[rmotyka]

Hi, thank you for very interesting article! But what do you think about using System.Threading.Channels for that purpose?

[linkdotnet]

Interesting thought - and it might work! The devil is in the detail.

[MirzaMerdovic]

Nice article!
As @rmotyka hinted, I've been wanting to do "this" with channels for a while now, but never got to it. General idea was to have IHostedService used as a collector and then use a "channel" to send logs, but it would definitely end up as a more complicated solution compared to this, in case it would proved to be a sane thing to do and not an over-engineered attempt to do logging

[linkdotnet]

Thanks @MirzaMerdovic !

That sounds interesting - and I do lean towards your last comment:

and not an over-engineered attempt to do logging

It might be - but it would also be interesting to get some learnings. What requirements did bring you towards that approach?

[MirzaMerdovic]

I was curious to see if the approach would give me good performance when doing high log velocity, i.e. pushing lots of traces, also the background process could be built to apply sampling strategies in case the message load is affecting app performances.

[StephenCleary]

I'm always wary of lock-free code. It's quite difficult to get right (across all architectures).

In this case, consider this situation:

• Thread 0 writes an item into a size-3 buffer that already has 2 items. It correctly determines that the buffer is not empty but gets preempted before the second if. _head is 0, _tail is 1, currentTail is 1, nextTail is 2.
• Other threads come in and manipulate the buffer. Specifically, one thread adds an item (making the queue full, _head at 0 and _tail at 2). Another thread comes in and removes a couple items; _head and _tail are both 2. Another thread comes in and writes two more items; _head is 2 and _tail is 1.
• Thread 0 resumes executing. The queue is full and yet it will still write since _tail and currentTail are equal.

[linkdotnet]

On your side here! I do like the concept behind lock-free ring buffers. I would argue one doesn't need it in ~99.9% of cases (don't quote me on this one). locks are somewhere in the realm of nanoseconds.

[tsvetelin-pavlov]

Isn't that just a queue with a capacity? Since the implementation doesn't override the head when its capacity is exhausted, why is it a 'ring buffer' and not just a 'fixed size / bounded queue'?
I am just curious.

[linkdotnet]

These are very interesting points - and I do agree. The current implementation just "rejects" new writings.

In my humble understanding of the concept, there are some differences between a fixed size queue and a ring buffer.

• the head and tai wrap around to the beginning of the array when they reach the end. So this is a pure circular behavior
• When you would dequeue something in a a queue, the position (index) would shift. That doesn't apply to this ring structure.

[MendelMonteiro]

You could also consider using a robust and performant ring buffer implementation from an existing project such as https://github.com/disruptor-net/Disruptor-net/blob/master/src/Disruptor/RingBuffer%601.cs . That implementation is not only lock-free but has been highly performance tuned.
Log4J uses the Java Disruptor under the hood to good effect.

[linkdotnet]

Oh highly agree - and thanks for the link to the library!