4 ms·

> It's writes to any address. It would be quite useless otherwise ... Ugh, you're right, of course. My brain hasn't quite woken up today :-/. I remember ther

> It's writes to any address. It would be quite useless otherwise ... Ugh, you're right, of course. My brain hasn't quite woken up today :-/. I remember there was some subtlety about read/acquire and write/release semantics that I consistently see different takes on. I think it was actually whether write/release semantics prevent any memory operation or only other writes from being reordered, e.g., is it a StoreStore+StoreLoad barrier or just StoreStore? And, similarly, whether read/acquire semantics imply LoadLoad+LoadStore or just LoadLoad. My understanding is that write-release only guarantees a StoreStore barrier, and read-acquire only guarantees LoadLoad (and maybe LoadStore for direct dependencies?). I have, however, seen the stronger guarantees implied many times. The point is, regardless of which is 'correct', you are likely to stumble across an incorrect explanation from someone who ostensibly knows what they're talking about. And that itself is a problem. I think the confusion stems from various languages and platforms providing stronger guarantees than are generally required to satisfy read/acquire and write/release. Java's `volatile`, I believe, requires both acquire+release semantics on writes. People get used to the stronger guarantees and then forget that language A's stronger guarantees aren't necessarily provided by language B.

dragontamer 7y ago
I think you're trying to talk about Independent-Read / Independent Write (IRIW) Sequential Consistency (https://stackoverflow.com/questions/50462948/acquire-release-vs-sequential-consistency-in-c11 https://stackoverflow.com/questions/50462948/acquire-release...) It seems like there are roughly 4 levels of consistency 1. Sequential Consistency -- Total ordering exists for all atomics. 2. Acquire-Release Consistency -- Acquire barrier ensures all memory operations before the Acquire "happened before" the read of the spinlock. Release barrier ensures all memory operations before the release barrier "happens before" the write of the spinlock. 3. Consume-Release Consistency -- C++11 hypothetical: has not been used by C++ Compilers yet. This weaker memory ordering is a guarantee in some older chips but very few people seem to understand it. 4. Relaxed Consistency -- Atomics remain atomic, but no ordering is specified. --------- It seems like #2 is sufficient for most cases, #1 is needed for a few obscure cases (the IRIW / Independent read-Independent write case). #3 is (probably) sufficient in cases where pointers are being used as the synchronization point, but very few programmers have studied consume-release and its straight up not-implemented in any major compiler yet. (Some CPUs do offer consume-release, which is why it is included in the C++11 standard). #4 is rare, but useful if anyone wants the absolute fastest and knows atomics are enough (ex: a global multithreaded counter)

dragontamer 7y ago

I think you're trying to talk about Independent-Read / Independent Write (IRIW) Sequential Consistency (https://stackoverflow.com/questions/50462948/acquire-release-vs-sequential-consistency-in-c11 https://stackoverflow.com/questions/50462948/acquire-release...) It seems like there are roughly 4 levels of consistency 1. Sequential Consistency -- Total ordering exists for all atomics. 2. Acquire-Release Consistency -- Acquire barrier ensures all memory operations before the Acquire "happened before" the read of the spinlock. Release barrier ensures all memory operations before the release barrier "happens before" the write of the spinlock. 3. Consume-Release Consistency -- C++11 hypothetical: has not been used by C++ Compilers yet. This weaker memory ordering is a guarantee in some older chips but very few people seem to understand it. 4. Relaxed Consistency -- Atomics remain atomic, but no ordering is specified. --------- It seems like #2 is sufficient for most cases, #1 is needed for a few obscure cases (the IRIW / Independent read-Independent write case). #3 is (probably) sufficient in cases where pointers are being used as the synchronization point, but very few programmers have studied consume-release and its straight up not-implemented in any major compiler yet. (Some CPUs do offer consume-release, which is why it is included in the C++11 standard). #4 is rare, but useful if anyone wants the absolute fastest and knows atomics are enough (ex: a global multithreaded counter)