Building a Fast Lock-Free Queue in Modern C++ from Scratch
blog.jaysmito.dev
Building a Fast Lock-Free Queue in Modern C++ from Scratch
1–10 of 42 posts
Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch
#2Nice article. There a few issues with your code however from a cursory glance; your dtor seems to allow for spurious/double frees due to custom deleter support (you wanna check up on that), you also seem to use seq_cst far too much even if not needed (you want to avoid them is queues as much as possible), lastly class FastQueueNodeSlot.. isn't aligned (plus 64b alignment is only a thing for amd64 cpus, apple silicon is larger).
Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch
#3Is this similar to moodycamel’s?
Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch
#4Once you use atomic cmpxchg you've lost a great deal of scalability because it implies a retry loop (internal or by the user)
The last thing you want is all of the threads failing to cmpxchg (spuriously or otherwise ) spinning on a shared cacheline
Real world alternatives show atomic xchg only solutions scale to hundreds of threads.
Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch
#5Once you use atomic cmpxchg you've lost a great deal of scalability because it implies a retry loop (internal or by the user) The last thing you want is all of the threads failing to cmpxchg (spuriously or otherwise ) spinning on a shared cacheline Real world alternatives show atomic xchg only solutions scale to hundreds of threads.
> Real world alternatives show atomic xchg only solutions scale to hundreds of threads
But notably only with certain workloads
Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch
#6Once you use atomic cmpxchg you've lost a great deal of scalability because it implies a retry loop (internal or by the user) The last thing you want is all of the threads failing to cmpxchg (spuriously or otherwise ) spinning on a shared cacheline Real world alternatives show atomic xchg only solutions scale to hundreds of threads.
> Real world alternatives show atomic xchg only solutions scale to hundreds of threads But notably only with certain workloads
Once you get to using custom lock free queues you should be picking something that matches your workload/broader design anyway.
Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch
#7Not trying to be critical, but there are a number of misspellings and grammatical issues and it was actually a breath of fresh air to be reminded while I was reading that a real human being wrote this. I feel a little inspired to turn off spell check for my own writing.
Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch
#8Nice article. There a few issues with your code however from a cursory glance; your dtor seems to allow for spurious/double frees due to custom deleter support (you wanna check up on that), you also seem to use seq_cst far too much even if not needed (you want to avoid them is queues as much as possible), lastly class FastQueueNodeSlot.. isn't aligned (plus 64b alignment is only a thing for amd64 cpus, apple silicon…
a C++ experienced programmer, I spoke recently to, told me that using new and delete is basically prohibited nowadays in C++ in favour of std::make_unique, std::make_shared etc.
Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch
#9Nice article. There a few issues with your code however from a cursory glance; your dtor seems to allow for spurious/double frees due to custom deleter support (you wanna check up on that), you also seem to use seq_cst far too much even if not needed (you want to avoid them is queues as much as possible), lastly class FastQueueNodeSlot.. isn't aligned (plus 64b alignment is only a thing for amd64 cpus, apple silicon…
a C++ experienced programmer, I spoke recently to, told me that using new and delete is basically prohibited nowadays in C++ in favour of std::make_unique, std::make_shared etc.
In many application code bases no doubt. But how do you think make_unique and make_shared are implemented?
Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch
#10Nice article. There a few issues with your code however from a cursory glance; your dtor seems to allow for spurious/double frees due to custom deleter support (you wanna check up on that), you also seem to use seq_cst far too much even if not needed (you want to avoid them is queues as much as possible), lastly class FastQueueNodeSlot.. isn't aligned (plus 64b alignment is only a thing for amd64 cpus, apple silicon…
a C++ experienced programmer, I spoke recently to, told me that using new and delete is basically prohibited nowadays in C++ in favour of std::make_unique, std::make_shared etc.
For 95% of all code that is correct. std::make_* is easy to use and prevents a lot of mistakes, while having no loss of performance. That last 5% though you are doing weird things and so need to do something manually. (as the other poster said, make_unique is implemented with new) Of course the 5% is overall. Some projects never have anything that gets into that last 5%, while others it is more like 50% of the code can't use make_*. If at all possible your use of new/delete should be limited to a data structure/container than handles it, and not scatters all over.