Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a Fast Lock-Free Queue in Modern C++ from Scratch

blog.jaysmito.dev

Post reply on HN
Print view View original

21–30 of 42 posts

Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch

#21

Post by smallstepforman »

bluGill wrote: post #10
p0w3n3d wrote: post #8

Earlier quoted context omitted.

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 c…

The unique_ptr destructor is called on scope exit, and there are times you want this earlier before other critical code.

Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch

#22

Post by will4274 »

pjmlp wrote: post #19
bluGill wrote: post #16

Earlier quoted context omitted.

I don't think adding unsafe will be possible - it will break too much existing code. We might be able to add something new that is only possible in an unsafe context, but there is too much existing code. However I do expect a [[safe]] profile (or perhaps several, depending on which paper you read) that everyone is encourage to opt-in to. Likely combines with compiler warnings and static analysis to encourage that use…

Check the WG21 mailing proposals. I was for Safe C++ paper, based on Circle experience, but it was shot down due to politics. So we're left with the profiles camp actually delivering, followed by the remaining compilers caring to actually implement them, otherwise it will be static and dynamic analysis as usual.

It wasn't shot down due to politics. It was shot down because it solved the wrong problem.

Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch

#23

Post by bluGill »

smallstepforman wrote: post #21
bluGill wrote: post #10

Earlier quoted context omitted.

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 c…

The unique_ptr destructor is called on scope exit, and there are times you want this earlier before other critical code.

you can call release or reset as needed if you want the delete to happen early - and if you forget an obscure code path it still gets deleted on scope exit which is probably good enough for that path.

Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch

#24

Post by jmalicki »

smallstepforman wrote: post #21
bluGill wrote: post #10

Earlier quoted context omitted.

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 c…

The unique_ptr destructor is called on scope exit, and there are times you want this earlier before other critical code.

That's why you can define your own scope to control that.

Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch

#26

Post by pjmlp »

will4274 wrote: post #22
pjmlp wrote: post #19

Earlier quoted context omitted.

Check the WG21 mailing proposals. I was for Safe C++ paper, based on Circle experience, but it was shot down due to politics. So we're left with the profiles camp actually delivering, followed by the remaining compilers caring to actually implement them, otherwise it will be static and dynamic analysis as usual.

It wasn't shot down due to politics. It was shot down because it solved the wrong problem.

Yeah, that is why there was a paper created specifically to kill any other proposal, by the profiles folks with WG21 majority, and ironically profiles are just as annotation heavy, but since it is profiles, it is alright.

I call that politics, and in the end the most likely outcome is that by C++29 nothing will be delivered by the profiles group, that is any better than using clang-tidy already today.

Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch

#27

Post by stackghost »

brcmthrowaway wrote: post #20

How can I make a lock free queue without OS support, ESP32?

I'd ask your friendly neighborhood LLM for design advice, but off the top of my head, so long as `static_assert(std::atomic::is_lock_free)` passes, you could build a lock-free SPSC queue with just plain ol' std::atomics and probably liberal use of `alignas()` calls

Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch

#28

Post by superxpro12 »

bluGill wrote: post #15
RossBencina wrote: post #12

Earlier quoted context omitted.

"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." For 95% of code std::unique_ptr has no loss of performance. Perhaps. Just remember that it is not a zero-cost abstraction, the compiler won't always be able to entirely eliminate the overhead: https://www.youtube.com/watch?v=rHIkrotSwcc

I watched that about 7 years ago when it first came out, and at an hour long I'm not about to watch it again... From what I can recall those are things that rarely are important. There is a cost, but in most real world code they only add a few nanoseconds - I have more important things to worry about.

As a firmware developer commonly operating on devices with 32MHz of cpu, i am offended sir.

Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch

#29

Post by charleslmunger »

bheadmaster wrote: post #17

> NOTE: Throughout our implementation we strictly use compare_exchange_strong, but the C++ standard suggests that for some systems like ARM it mighe be a better idea to run a loop with compare_exchange_weak for better performance. The problem with that is a compare_exchange_weak call may fail spuriously, which essentially it can randomly fail even if everything is correct, thus it makes code code a bit more complicat…

This is overstated in value; on arm systems with LSE it's faster to use that even for weak operations than to use ll/sc. Even if you are limited to ll/sc the compiler may not put your cas-loop body into the ll/sc region as there's limitations on how many and what type of instructions are permitted there.

Re: Building a Fast Lock-Free Queue in Modern C++ from Scratch

#30

Post by saghm »

pjmlp wrote: post #14
RossBencina wrote: post #9

Earlier quoted context omitted.

In many application code bases no doubt. But how do you think make_unique and make_shared are implemented?

With what will most likely become [[unsafe]] profile in C++29, assuming WG21 actually gets their profiles story right.

Classic C++, any issue is at most three years away from going away! There will definitely not be any other issues that are also three years from getting fixed when you reach that year though
Post reply on HN