Joseph Schuchart
Joseph Schuchart
I just wanted to use STACK on a large community project (I remember it being useful a few years back) but then saw this issue. I guess there is no...
Thanks for your quick feedback and sorry for not checking the FAQ beforehand. I checked and do not see these false positives with the self-built versions. It is not clear...
Closing in favor of https://github.com/open-mpi/ompi/pull/10613
I think the assumption is that single-elements loads and stores are atomic, yet not synchronizing. OPAL provides `opal_atomic_rmb` and `opal_atomic_wmb` to order loads and stores, respectively. Would that work for...
According to https://developer.arm.com/documentation/ddi0487/gb/, B2.2.1 64bit load/stores are atomic on 64-bit arm. Unaligned 64bit load/store is UB in C so I doubt the compiler will come to the rescue here (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf...
I am not opposed to having simple atomic load/stores in opal. However, I don't think there is a use-case for it right now because inter-thread synchronization is synchronized through locks...
@gkatev If you need such infrastructure you can of course add it to your local branch. If that ever gets upstreamed we will have a use-case for atomic load/store and...
Turns out, *all* increment/decrement/assignment accesses to an `_Atomic` variable are atomic with sequential consistency [1]. This nullifies all the efforts to avoid atomic operations if not needed (in the `opal_thread_*`...
> So, you refer to `*addr = *addr operator delta` (in `OPAL_THREAD_DEFINE_ATOMIC_OP`), which when not using threads is meant to be non-atomic (?) That's right, it's supposed to be non-atomic...