jackaudio
Add GNU/Hurd support
volatileby itself doesn't imply cache flushing. But synchronization memory coherency properties do indeed.
You're correct, thanks for pointing that out. My understanding distils to "if it's not memory-mapped I/O or signals it doesn't need volatile" and I'm sure I get the intricacies wrong in one way or another.
The change looks good to me. I tried to figure out if there might be possible pitfalls going from __sync_* to __atomic_* by reading glibc sources, but since it's so heavily layered with macros it proved more difficult than just casually browsing a repo. Looking elsewhere, at least glib seems to treat __atomic_compare_exchange_n with __ATOMIC_SEQ_CST as equivalent to __sync_bool_compare_and_swap:
https://github.com/GNOME/glib/blob/68388cf7f753d91686d2a50d74e760d28dab27a3/glib/gatomic.h#L176 https://github.com/GNOME/glib/blob/68388cf7f753d91686d2a50d74e760d28dab27a3/glib/gatomic.h#L402
Side note: I feel an urge to start chipping away at the entire atomic mess, or at least the parts that are very clearly unnecessary. I'm mainly referring to INC_ATOMIC and DEC_ATOMIC here, as they have very limited actual use and can be replaced with standard std::atomic increment and decrement. These don't even need CAS.
if there might be possible pitfalls going from
__sync_*to__atomic_*
It is clear from the gcc source for __sync_*: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/builtins.cc;h=9d106405f79512fe3833c9a830a0f317937bd08a;hb=HEAD#l6575
so __sync_*_compare_and_swap are strictly equivalent to __atomic_compare_and_swap with no weak and SEQ_CST
if there might be possible pitfalls going from
__sync_*to__atomic_*It is clear from the gcc source for
__sync_*: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/builtins.cc;h=9d106405f79512fe3833c9a830a0f317937bd08a;hb=HEAD#l6575so
__sync_*_compare_and_swapare strictly equivalent to__atomic_compare_and_swapwith no weak andSEQ_CST
OK, thanks. Also I just realized I said glibc when I meant gcc sources; brain fart.