> Disclaimer: An earlier version of this post claimed the structure is wait-free, this is incorrect. Being wait-free requires that failure or suspension of any thread can’t cause failure or suspension of another thread. This queue in fact does not fulfill that requirement. The main section which discusses the wait bounds of queue operations has been amended to reflect this, but other parts of this article have not been. As such there may parts of the text which refer to this as a wait-free queue, which it is not. I chose to keep those sections to avoid rewriting chunks of this post after it was already posted. Thanks for the correction Reddit user matthieum!
Thanks. I jumped at the headline. I'd be happy with wait-free MPSC. I haven't checked in for a while. Have there been any breakthroughs in low-complexity wait-free queues in the past 10 years?
> There are trade-offs everywhere, and it's best to pick the data structure that fits your needs just like any other problem.
That part I think is most crucial. Neither "Lock-free" nor "Wait-free" are vague terms for how awesome a thing is, they're specific properties which are expensive to provide, if you need such a property it was indispensable, if you don't need it then you can likely do better without it.
Exactly. I mentioned that those queues aren't formally obstruction-free because the context of the conversation was new developments in wait-free queues, even though I have only needed the guarantee once in my career and end up using descendants of the Vyukov MPMC cycle queue in practically all other cases because they are better on the metrics that count, like speed.
I don't think any of my immediate opportunities are "real-time industrial automation" shaped, but, can't hurt to ask: Do you think it was the work that inherently was the worst ever, or was there some other enviromental factor (e.g. terrible wages, for some reason your office was up six flights of stairs with no elevator, colleague insisted on playing music from your least favourite genre at maximum volume) ?
Not a ton, the inexorable march to wider scalar dispatch, deeper pipelines, and ever less uniform geometries (I pine for the halcyon days of two NUMA modes with a QPI bar) has made asymmetrical fencing juicy enough to be be worth the squeeze at the margins, you weren't seeing a ton of `asm volatile ""` on one side and `membarrier()` on the other a decade ago and you'll see that now.
But I think Nathan Bronson's work out of IIRC Standford about 10 or 15 years ago is still more or less the canvas you paint on.
Perhaps I missed it but there didn't appear to be discussion of false sharing between the N individual data slots. It might be beneficial to pad each slot to a cache line width (or at least less slots per line), and/or using some kind of bijective hashing on the slot lookup so that sequential tickets don't access adjacent slots.
If you align and pad each slot there won't be any false sharing and the stream prefetcher can kick in if there's only one producer or consumer.
If you use bijective hashing you reduce false sharing without aligning and padding. This can save memory at the expense of the stream prefetcher never kicking in.
Title sounds like auto translated title for spicy Japanese movie (sorry, just honest feedback).
Agent had several comments (even on recent repo). I wrote much worse code, good for research project, but I would pass. The post is from march 2026 though.
Perhaps add more disclaimers about limitations. Or add section to explain most common agent comments.
It's also a joke because girls definitely don't care about "Fast MPMC Queues with Bounded Waiting" at all. We can estimate the HN audience to be ≈95% male.
You can't fathom the idea of women being smarter and more capable than you so you have to resort to shifting the goal post over and over. "No women would ever enjoy this", "No one actually knows a woman that would enjoy this", "Even if you know a woman I bet she's not a biological woman". Glancing over your post history I can see that it's nothing more than posting other people's work, which considering your miserable understanding of statistics, is a blessing that spares the world from having to bear your idiocy. I'm not going to be talked down to by some good-for-nothing man who has never created anything of value in his life.
I'm not an HN user because this website sucks, I was informed that someone shared my post here by email so I went to check it out and remember why I don't use this site. You're a woman-repellent and this place is full of the likes of you, that's the reason you don't see many women here, and it's the same reason you don't see women in real life.
In summary, since I know you can't handle too many words and summaries are all you read: Go fuck yourself.
If you wanna be pedantic, the set of people who care about fast mpmc queues with bounded waiting is very very tiny across even the whole population of HN, let alone the broader populace. I would posit that <5% of HN even knows what mpmc queues are.
So of any statement of "<X broad group> just wanna have fast mpmc queues" should be obviously taken as a parody.
Because it would not even pass initial code review for most developers. Most people use short review prompt, with yes/no answers.
Imagine the code compilers (or some analysis tool) gives several concurrency and memory warnings. It has easy workaround (just annotate strange code, with links to explanations that this is workaround for low level bugs).
I am too tired of shitty "safe" Rust code, with 'unsafe' section around every library call (not case here, just an example)! Be clear with that, it takes 15 minutes and 10 cents!
This project could have correct concurrent code and design, but around much narrower definitions. But most people will not go too deep with review to find it!
This was the very best bounded MPMC queue when I last looked into these things years ago, and as far as descendants of the Vyukov MPMC cycle queue go, I don't think it's possible to do much better.
I think your citation date is off, by the way. As far as I can tell, it was first published in January 2011.
unsafe impl<T, const N: usize> Sync for WFQueue<T, N> {}
unsafe impl<T, const N: usize> Send for WFQueue<T, N> {}
These impls are unsound, because neither constrains `T` to be `Sync`/`Send`. As-written this would let you declare a `WFQueue<Rc<T>, N>` and pass non-atomic-refcount pointers between threads.
52 comments
[ 0.22 ms ] story [ 49.6 ms ] threadClassy disclaimer! matthieum's (long) reddit comment is also an informative read: https://www.reddit.com/r/rust/comments/1up0uhg/girls_just_wa...
[0] https://arxiv.org/pdf/2201.02179
It originally required double-width CAS, but IIRC in recent years someone figured out how to remove this to make it more portable
Best reference I could find from cursory google:
https://ppopp23.sigplan.org/details/PPoPP-2023-papers/2/The-...
That part I think is most crucial. Neither "Lock-free" nor "Wait-free" are vague terms for how awesome a thing is, they're specific properties which are expensive to provide, if you need such a property it was indispensable, if you don't need it then you can likely do better without it.
[1]: https://github.com/dorjoy03/dsync/blob/master/src/mpmc_queue...
But I think Nathan Bronson's work out of IIRC Standford about 10 or 15 years ago is still more or less the canvas you paint on.
If you align and pad each slot there won't be any false sharing and the stream prefetcher can kick in if there's only one producer or consumer.
If you use bijective hashing you reduce false sharing without aligning and padding. This can save memory at the expense of the stream prefetcher never kicking in.
Agent had several comments (even on recent repo). I wrote much worse code, good for research project, but I would pass. The post is from march 2026 though.
Perhaps add more disclaimers about limitations. Or add section to explain most common agent comments.
I definitely know some girls who'd love this, and see this as having fun.
I'm not an HN user because this website sucks, I was informed that someone shared my post here by email so I went to check it out and remember why I don't use this site. You're a woman-repellent and this place is full of the likes of you, that's the reason you don't see many women here, and it's the same reason you don't see women in real life.
In summary, since I know you can't handle too many words and summaries are all you read: Go fuck yourself.
So of any statement of "<X broad group> just wanna have fast mpmc queues" should be obviously taken as a parody.
At which point... why rail on this?
Yes, but even of those who do care the vast majority will obviously be male.
Shouldn't your agent explain its own comments? why would the author of a fast queue care what your agent says?
Imagine the code compilers (or some analysis tool) gives several concurrency and memory warnings. It has easy workaround (just annotate strange code, with links to explanations that this is workaround for low level bugs).
I am too tired of shitty "safe" Rust code, with 'unsafe' section around every library call (not case here, just an example)! Be clear with that, it takes 15 minutes and 10 cents!
This project could have correct concurrent code and design, but around much narrower definitions. But most people will not go too deep with review to find it!
And if it's got value for you, hey, it's open source. Spend the 15 minutes and 10 cents, it's a bargain.
I don't think this is true at all.
I don't. I review code by hand, like I have for 20 years. I think you might have some sample bias.
I think your citation date is off, by the way. As far as I can tell, it was first published in January 2011.
The fix is straightforward:
I.e., WFQueue is only Sync if T is Sync, and likewise for Send.Actually, later on, the code makes a similar mistake, but only for one impl.
Sounds like fun.