31–40 of 42 posts
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
> 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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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
By the way, it is also classical Web standards, C, Vulkan, OpenCL, and everything else that has a similar process.
Ideally we should have gotten rid of C and C++, but I haven't yet found a better Typescript for C.
Earlier quoted context omitted.
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
Most local LLMs I've used are not particularly great with the advice unfortunately, probably because I haven't spent thousands of dollars on new hardware recently
Anyways. Ask Claude.
Earlier quoted context omitted.
Most local LLMs I've used are not particularly great with the advice unfortunately, probably because I haven't spent thousands of dollars on new hardware recently
Edited my comment for clarity. I meant "friendly local" as a euphemism, like "neighborhood pub". Anyways. Ask Claude.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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
Actually no, because you are missing the time between standard being ratified and actuality being widely available in all major compilers. By the way, it is also classical Web standards, C, Vulkan, OpenCL, and everything else that has a similar process. Ideally we should have gotten rid of C and C++, but I haven't yet found a better Typescript for C.
Not 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.
> 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.
On any plaform which implements strong exchange with zero overhead over weak exchange, we can safely assume they compile to the same thing, and use weak. The only reason to use `strong` is if you have a one-shot CAS operation and you don't want to write a retry loop.