search for: memory_order_release

Ptr member of ManagedStaticBase is now atomic. In ManagedStaticBase::RegisterManagedStatic we have such code: void *Tmp = Creator(); Ptr.store(Tmp, std::memory_order_release); DeleterFn = Deleter; // Add to list of managed statics. Next = StaticList; StaticList = this; StaticList is not atomic and not guarded by any fence. The same applies to the members DeleterFn and Next. Doesn't it seem reasonable to change the code to DeleterF...

...On Mon, Dec 26, 2016 at 9:20 AM, Viacheslav Nikolaev < viacheslav.nikolaev at gmail.com> wrote: > Ptr member of ManagedStaticBase is now atomic. > In ManagedStaticBase::RegisterManagedStatic we have such code: > > void *Tmp = Creator(); > > Ptr.store(Tmp, std::memory_order_release); > DeleterFn = Deleter; > > // Add to list of managed statics. > Next = StaticList; > StaticList = this; > > > StaticList is not atomic and not guarded by any fence. > The same applies to the members DeleterFn and Next. > > Doesn't it se...

...itizer; // NOLINT 3. These are the definitions that conflict in this particular 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 l...

...ct in this particular 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. Re...

...int pthread_create(...) > { > if (updateshardcount()) { > shardlock(); > if (updateshardcount()) { > int newcount = computeshardcount(); > for (int i = oldcount; i < newcount; i++) > shard[i] = malloc(ncounter*sizeof(uint64)); > atomic_store(&shardmask, newcount-1, memory_order_release); > } > shardunlock(); > } > ... > } > > > If we go with this scheme, for tid I would do: __thread threadid; int pthread_create(...) { threadid = goohhash(gettid()); ... } void userfunc() { int tid = threadid+1; threadid = tid; // use tid in profiling...

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

...hardcount()) { >>> shardlock(); >>> if (updateshardcount()) { >>> int newcount = computeshardcount(); >>> for (int i = oldcount; i < newcount; i++) >>> shard[i] = malloc(ncounter*sizeof(uint64)); >>> atomic_store(&shardmask, newcount-1, memory_order_release); >>> } >>> shardunlock(); >>> } >>> ... >>> } >>> >>> >>> >> If we go with this scheme, for tid I would do: >> >> __thread threadid; >> >> int pthread_create(...) >> { >> threadid...

On Apr 17, 2014, at 2:04 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Thu, Apr 17, 2014 at 1:27 PM, Justin Bogner <mail at justinbogner.com> wrote: > Chandler Carruth <chandlerc at google.com> writes: > > if (thread-ID != main's thread-ID && shard_count < std::min(MAX, NUMBER_OF_CORES)) { > > shard_count = std::min(MAX,

...xed); x.store(something, memory_order_relaxed); In 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,...

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