4 ms·

Don't most people use C++11 atomics now? You have SeqCst, Release, Acquire, and Relaxed (with Consume deprecated due to the difficulty of implementing it). You

Don't most people use C++11 atomics now? You have SeqCst, Release, Acquire, and Relaxed (with Consume deprecated due to the difficulty of implementing it). You can do loads, stores, and exchanges with each ordering type. Zig, Rust, and C all use the same orderings. I guess Java has its own memory model since it's been around a lot longer, but most people have standardized around C++'s design. Which is a slight shame since Load-Linked/Store-Conditional is pretty cool, but I guess that's limited to ARM anyways, and now they've added extensions for CAS due to speed.

superxpro12 7mo ago
I've taken an interest in lock-free queues for ultra-low power embedded... think Cortex-m0, or even avr/pic. Things get interesting when you're working with a cpu that lacks the ldrex/strem assembly instructions that makes this all work. I think youre only options at that point are disable/enable interrupts. IF anyone has any insights into this constraint I'd love to hear it.
- loeg 7mo ago
  For ultra low-power embedded, wouldn't a mutex approach work just fine? You're running on a single core anyway.
  - dalvrosa 7mo ago
    I'm not sure about the single-core scenario, but would love to learn if someone else wants to add something In reality multiple threads for single core doesn't make much sense right?
    - loeg 7mo ago
      > In reality multiple threads for single core doesn't make much sense right? Not necessarily, I think -- depends what you're doing.
loeg 7mo ago
LL/SC is still hinted at in the C++11 model with std::atomic<T>::compare_exchange_weak: https://en.cppreference.com/w/cpp/atomic/atomic/compare_exchange.html https://en.cppreference.com/w/cpp/atomic/atomic/compare_exch...
j_seigh 7mo ago
My impression was LL/SC had forward progress issues due to the difficulties of preventing false sharing of the locked memory reservation region. Updates into that region would keep invalidating the lock. I had a version of atomic* reference counting that used LL/SC on a ppc mac mini along side x86 versions using cmpxchg16b. Code used to be sourceforge before it went to the dark side. An early posting of the idea before I got around to implementing it. https://groups.google.com/g/comp.programming.threads/c/HZqn5v3l8aQ/m/4bCzrRU8S_gJ?pli=1 https://groups.google.com/g/comp.programming.threads/c/HZqn5... * Std::shared_ptr and Rust ARC aren't actually atomic. You have to own a reference to do a copy. The are what POSIX calls thread-safe. With atomic reference counting, if you copy a reference, you either get a valid reference or null. Like Java references.

superxpro12 7mo ago

I've taken an interest in lock-free queues for ultra-low power embedded... think Cortex-m0, or even avr/pic. Things get interesting when you're working with a cpu that lacks the ldrex/strem assembly instructions that makes this all work. I think youre only options at that point are disable/enable interrupts. IF anyone has any insights into this constraint I'd love to hear it.

loeg 7mo ago
For ultra low-power embedded, wouldn't a mutex approach work just fine? You're running on a single core anyway.
- dalvrosa 7mo ago
  I'm not sure about the single-core scenario, but would love to learn if someone else wants to add something In reality multiple threads for single core doesn't make much sense right?
  - loeg 7mo ago
    > In reality multiple threads for single core doesn't make much sense right? Not necessarily, I think -- depends what you're doing.

loeg 7mo ago

LL/SC is still hinted at in the C++11 model with std::atomic<T>::compare_exchange_weak: https://en.cppreference.com/w/cpp/atomic/atomic/compare_exchange.html https://en.cppreference.com/w/cpp/atomic/atomic/compare_exch...

j_seigh 7mo ago

My impression was LL/SC had forward progress issues due to the difficulties of preventing false sharing of the locked memory reservation region. Updates into that region would keep invalidating the lock. I had a version of atomic* reference counting that used LL/SC on a ppc mac mini along side x86 versions using cmpxchg16b. Code used to be sourceforge before it went to the dark side. An early posting of the idea before I got around to implementing it. https://groups.google.com/g/comp.programming.threads/c/HZqn5v3l8aQ/m/4bCzrRU8S_gJ?pli=1 https://groups.google.com/g/comp.programming.threads/c/HZqn5... * Std::shared_ptr and Rust ARC aren't actually atomic. You have to own a reference to do a copy. The are what POSIX calls thread-safe. With atomic reference counting, if you copy a reference, you either get a valid reference or null. Like Java references.