search for: atomic_thread_fence

struct { volatile int flag; int value; } s; int get_value_when_ready() { while (s.flag) ; __sync_synchronize(); return s.value; } This is "valid" legacy code on some processors, yet it's not valid to replace __sync_synchronize with an atomic_thread_fence because, in theory, LLVM could hoist the load of s.value. In practice it currently doesn't, but it may in the future if my understanding is correct. My main point is that LLVM needs to support code that was written before C and C++ got a memory model, it doesn't matter that it's undefi...

Hi, TL;DR: should we add a new memory ordering to fences? ``fence seq_cst`` is currently use to represent two things: - GCC-style builtin ``__sync_synchronize()`` [0][1]. - C11/C++11's sequentially-consistent thread fence ``std::atomic_thread_fence(std::memory_order_seq_cst)`` [2]. As far as I understand: - The former orders all memory and emits an actual fence instruction. - The latter only provides a total order with other sequentially-consistent loads and stores, which means that it's possible to move non-sequentially-consistent loa...

...at google.com>: > Hi, > > TL;DR: should we add a new memory ordering to fences? > > > ``fence seq_cst`` is currently use to represent two things: > - GCC-style builtin ``__sync_synchronize()`` [0][1]. > - C11/C++11's sequentially-consistent thread fence > ``std::atomic_thread_fence(std::memory_order_seq_cst)`` [2]. > > As far as I understand: > - The former orders all memory and emits an actual fence instruction. > > - The latter only provides a total order with other > sequentially-consistent loads and stores, which means that it's > possible to mo...

...atile int flag; > int value; > } s; > > int get_value_when_ready() { > while (s.flag) ; > __sync_synchronize(); > return s.value; > } > > This is "valid" legacy code on some processors, yet it's not valid to > replace __sync_synchronize with an atomic_thread_fence because, in > theory, LLVM could hoist the load of s.value. In practice it currently > doesn't, but it may in the future if my understanding is correct. > > My main point is that LLVM needs to support code that was written > before C and C++ got a memory model, it doesn't mat...

Hi all, I'm currently working on implementing ACLE extensions for ARM. There are some memory barrier intrinsics, i.e.__dsb and __isb that require the compiler not to reorder instructions around their corresponding built-in intrinsics(__builtin_arm_dsb, __builtin_arm_isb), including non-memory-access instructions.[1] This is currently not possible. It is sometimes useful to prevent the

...ular, global objects of type "volatile sig_atomic_t" can be read and written between signal handlers in a thread and that thread's main control flow without locking. C++0x also defines an atomic_signal_fence(memory_order) that only synchronizes with signal handlers, in addition to the atomic_thread_fence(memory_order) that synchronizes to other threads. See [atomics.fences] > I'm not familiar with what synchronization occurs as > part of the interrupt process, but I'd verify it before making too > many assumptions. > >> This sequence that SBCL does today with its internal...

On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote: > Hi, thanks everyone for all the comments. I think maybe I wasn't clear that > I *only* care about atomicity w.r.t. a signal handler interruption in the > same thread, *not* across threads. Therefore, many of the problems of > cross-CPU atomicity are not relevant. The signal handler gets invoked via

...of type "volatile sig_atomic_t" can be read > and written between signal handlers in a thread and that thread's main > control flow without locking. C++0x also defines an > atomic_signal_fence(memory_order) that only synchronizes with signal > handlers, in addition to the atomic_thread_fence(memory_order) that > synchronizes to other threads. See [atomics.fences] Very interesting, and thanks for the clarifications. I'm not particularly familiar with either those parts of C or C++0x, although it's on the list... =D >> I'm not familiar with what synchronization occ...

On Jan 4, 2010, at 4:35 AM, Chandler Carruth wrote: > Responding to the original email... > > On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote: >> In working on an LLVM backend for SBCL (a lisp compiler), there are >> certain sequences of code that must be atomic with regards to async >> signals. > > Can you define exactly what