search for: memory_order_seq_cst

Quoting Tim Northover <t.p.northover at gmail.com>: > On 24 April 2015 at 13:53, Tyler Denniston <tyler at csail.mit.edu> wrote: >> I'm wondering how I can create an atomic load and add instruction for >> floating point values. If I use IRBuilder::CreateAtomicRMW() I get the >> error message: "atomicrmw operand must have integer type". > >

Hi, what's the current status of the memory-ordered operations described in https://docs.google.com/Doc?docid=0AYWBeVVqyP7dZGRiNG1oeHpfMjJkejVnOThkZA&hl=en.&pli=1 i.e. the ones for "load acquire", "store release" etc. for C++0x atomics, not the older ones for the __sync intrinsics? The specification looks good - is it just waiting to be implemented? Al --

...lar case, but this problem could reoccur in the future with other symbols as well: enum memory_order { memory_order_relaxed = 1 << 0, memory_order_consume = 1 << 1, memory_order_acquire = 1 << 2, memory_order_release = 1 << 3, memory_order_acq_rel = 1 << 4, memory_order_seq_cst = 1 << 5 }; We currently have a workaround (in the system header) that makes this non-blocking, but it would be good to cleanly address this problem. Removing the "using namespace" from the header seems like the cleanest solution. WDYT? Thanks, Anna. -------------- next part -----...

> } while (__c11_atomic_compare_exchange_weak( > addr, &oldval, newval, memory_order_seq_cst, memory_order_relaxed)); Actually, I think this condition is inverted. Should be "while (!_c11...". Sorry about that. Tim.

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 loads and stores around it....

...ymbols as well: >> >> enum memory_order { >> memory_order_relaxed = 1 << 0, >> memory_order_consume = 1 << 1, >> memory_order_acquire = 1 << 2, >> memory_order_release = 1 << 3, >> memory_order_acq_rel = 1 << 4, >> memory_order_seq_cst = 1 << 5 >> }; >> >> >> We currently have a workaround (in the system header) that makes this >> non-blocking, but it would be good to cleanly address this problem. Removing >> the "using namespace" from the header seems like the cleanest soluti...

...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-consis...

...uld 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...

On Tue, Jun 7, 2016 at 4:02 PM, Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > (+CC LLVM dev - I'd dropped it in my original reply unintentionally and > just noticed.) > > On 06/07/2016 01:35 PM, Philip Reames wrote: > >> (This was written in a rush. There may be mistakes; if so I'll try to >> correct later.) >> >> At the

...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'...

...n this case the compiler is free to order load/stores to x, in different threads, any why it feels fit. The full set of relaxed options are defined by the enumeration: typedef enum memory_order { memory_order_relaxed, memory_order_acquire, memory_order_release, memory_order_acq_rel, memory_order_seq_cst } memory_order; In the case of a default consistency model memory fences are not required but, in general, this is no longer the case for the relaxed model and C++ provides a family of fence operations, one per type of atomic (i.e. bool, address, and integral types); the bool fence operation is d...

Hi Ben, Vacation is always a good thing. Hope you had a good one. In my mind, having a more general memory consistency model is going to be very useful in LLVM in the future. It is still a little unclear to me what we should support. I haven't looked at what C++ is considering for their model. Are they going to support different relaxations models like relaxing write to read or