Live data from Hacker News

Put a ring on it: a lock-free MPMC ring buffer

h4x0r.org

11–20 of 46 posts

Re: Put a ring on it: a lock-free MPMC ring buffer

#11

Strange to see a lock-free ring buffer without seeing mention of LMAX/Martin Thompson's Java Disruptor ( https://github.com/LMAX-Exchange/disruptor )

Eh, I get it. I also independently came up with these MPMC approaches before hearing about LMAX. They're not entirely trivial but they do follow fairly naturally from the problem space when you really think about it. It's a good piece of engineering, but the one thing that's really unique about LMAX is the amount of advertising it gets.

Re: Put a ring on it: a lock-free MPMC ring buffer

#12
post #5

I wrote my first SPSC circular buffer implementation in TS upon reading the previous post on futex [0] from the same author. It was more intricate than it had seemed, until I finally sat down and wrote my own code. [0]: https://h4x0r.org/futex/ discussion: https://news.ycombinator.com/item?id=44951563

FYI: I have made a SPSC circular buffer for swap data in a pair of process: https://github.com/starwing/kaze-core

maybe that is what you want.

Re: Put a ring on it: a lock-free MPMC ring buffer

#14
post #6

This isn't that new. (see: FASTER: A Concurrent Key-Value Store with In-Place Updates. 2018 ACM SIGMOD International Conference on Management of Data and related papers) However, this is well written and very easy to read.

Also this Nim library: https://github.com/nim-works/loony Which is based on: https://ieeexplore.ieee.org/document/9490347

The paper is annoyingly difficult to locate but the author's implementation is at https://github.com/oliver-giersch/looqueue-rs

Re: Put a ring on it: a lock-free MPMC ring buffer

#15
post #11

Strange to see a lock-free ring buffer without seeing mention of LMAX/Martin Thompson's Java Disruptor ( https://github.com/LMAX-Exchange/disruptor )

Eh, I get it. I also independently came up with these MPMC approaches before hearing about LMAX. They're not entirely trivial but they do follow fairly naturally from the problem space when you really think about it. It's a good piece of engineering, but the one thing that's really unique about LMAX is the amount of advertising it gets.

> the one thing that's really unique about LMAX is the amount of advertising it gets.

Virtually zero? I have to go out of my way to remind HN it exists while everyone is 300+ comments deep into reinventing the wheel on a ~quarterly basis.

Re: Put a ring on it: a lock-free MPMC ring buffer

#16

Is there any chance to modify Vyukov's MPMC queue implement ( https://www.1024cores.net/home/lock-free-algorithms/queues/b... ) to support drop handler? That work doesn't need 128 bit CAS.

You can use a 64-bit CAS if you want to use a 32-bit epoch and a pointer compression scheme of any kind, or just a 32-bit index into regions that are thread specific. I think I did the later when I did the original work, using the core primitive to build ring buffers that have arbitrary sized slots instead of 64-bit slots (which requires a bit of additional gymnastics, but the basic trick is to have the ring index into a bigger ring that you can FAA into, where the bigger ring has more slots by at least the max number of threads (I use this primitive heavily still for in-memory debug logging). Maybe at some point I'll do an article on that too.

Re: Put a ring on it: a lock-free MPMC ring buffer

#17
post #16

Is there any chance to modify Vyukov's MPMC queue implement ( https://www.1024cores.net/home/lock-free-algorithms/queues/b... ) to support drop handler? That work doesn't need 128 bit CAS.

You can use a 64-bit CAS if you want to use a 32-bit epoch and a pointer compression scheme of any kind, or just a 32-bit index into regions that are thread specific. I think I did the later when I did the original work, using the core primitive to build ring buffers that have arbitrary sized slots instead of 64-bit slots (which requires a bit of additional gymnastics, but the basic trick is to have the ring index in…

BTW, should be noted that the need to issue a cache line lock on x86 does seem to slow down 128-bit CAS quite a bit on x86-64 platforms. On arm64, there's no reason to skimp with a 64-bit CAS.

Re: Put a ring on it: a lock-free MPMC ring buffer

#18
post #10
post #7

Looks like a good write up, but I'd caution that some of the statements about memory models aren't completely accurate. The terms relaxed, acquire, and release refer to how an atomic operation is ordered against other accesses to memory. Counter to what the article states, a relaxed atomic is still atomic, meaning that it cannot tear and, for RMW atomic, no other access can go between the read and the write. But a re…

Yes, I meant to clarify the memory model discussion; I had tried to simplify and did a poor job; I got similar feedback after it was published, and never remembered to get to it. Will try to do it soon, though it's about the worst time for this to have hit, not sure when I'll be able to sit down for it, but will try to get it done in the next day. Hopefully it doesn't wait until next time it gets some views.

I also note that you don't mention the cache-line contention issue when accessing atomics in a multi-threaded context. That's a huge performance issue with lock-free constructs.

Re: Put a ring on it: a lock-free MPMC ring buffer

#19
Seems hung up on defining a ring buffer as something non-blocking (dropping). Having used ring buffers in both software and hardware systems for 40 years, we always called them ring buffers without this distinction. We would have called them all ring buffers. One nice thing about them is that it’s very easy to pass buffers back and forth between a single producer and single consumer without any locks or fancy memory atomics. All you need is a guarantee that memory writes occur in order. The AMD LANCE Ethernet controller (and many later derivatives) used this scheme to allow smooth overlapping of software frame processing with hardware transmission and reception way back in the 1980s.

Re: Put a ring on it: a lock-free MPMC ring buffer

#20
post #10
post #7

Looks like a good write up, but I'd caution that some of the statements about memory models aren't completely accurate. The terms relaxed, acquire, and release refer to how an atomic operation is ordered against other accesses to memory. Counter to what the article states, a relaxed atomic is still atomic, meaning that it cannot tear and, for RMW atomic, no other access can go between the read and the write. But a re…

Yes, I meant to clarify the memory model discussion; I had tried to simplify and did a poor job; I got similar feedback after it was published, and never remembered to get to it. Will try to do it soon, though it's about the worst time for this to have hit, not sure when I'll be able to sit down for it, but will try to get it done in the next day. Hopefully it doesn't wait until next time it gets some views.

> Co-founder of Crash Override.

<3

Post reply on HN