memory-fences

Assuming that aligned pointer loads and stores are naturally atomic on the target platform, what is the difference between this: // Case 1: Dumb pointer, manual fence int* ptr; // ... std::atomic_thread_fence(std::memory_order_release); ptr = new int(-4); this: // Case 2: atomic var, automatic fence std::atomic<int*> ptr; // ... ptr.store(new int(-4), std::memory_order_release); and this: // Case 3: atomic var, manual fence std::atomic<int*> ptr; // ... std::atomic_thread_fence(std::memory_order_release); ptr.store(new int(-4), std::memory_order_relaxed); I was under the impression that they

If we have the following code in C#: int a = 0; int b = 0; void A() // runs in thread A { a = 1; Thread.MemoryBarrier(); Console.WriteLine(b); } void B() // runs in thread B { b = 1; Thread.MemoryBarrier(); Console.WriteLine(a); } The MemoryBarriers make sure that the write instruction takes place before the read. However, is it guaranteed that the write of one thread is seen by the read on the other thread? In other words, is it guaranteed that at least one thread prints 1 or both thread could print 0 ? I know that several questions exist already that are relevant to "freshness" and

There are a couple of questions on this site asking whether using a volatile variable for atomic / multithreaded access is possible: See here , here , or here for example. Now, the C(++) standard conformant answer is obviously no . However, on Windows & Visual C++ compiler, the situation seems not so clear. I have recently answered and cited the official MSDN docs on volatile Microsoft Specific Objects declared as volatile are (...) A write to a volatile object (volatile write) has Release semantics; a reference to a global or static object ? that occurs before a write to a volatile object in

In Java 8 three memory barrier instructions were added to Unsafe class ( source ): /** * Ensures lack of reordering of loads before the fence * with loads or stores after the fence. */ void loadFence(); /** * Ensures lack of reordering of stores before the fence * with loads or stores after the fence. */ void storeFence(); /** * Ensures lack of reordering of loads or stores before the fence * with loads or stores after the fence. */ void fullFence(); If we define memory barrier with the following way (which I consider more or less easy to understand): Consider X and Y to be operation types

Ok, I have been reading the following Qs from SO regarding x86 CPU fences ( LFENCE , SFENCE and MFENCE ): Does it make any sense instruction LFENCE in processors x86/x86_64? What is the impact SFENCE and LFENCE to caches of neighboring cores? Is the MESI protocol enough, or are memory barriers still required? (Intel CPUs) and: http://www.puppetmastertrading.com/images/hwViewForSwHackers.pdf https://onedrive.live.com/view.aspx?resid=4E86B0CF20EF15AD!24884&app=WordPdf&authkey=!AMtj_EflYn2507c and I must be honest I am still not totally sure when a fence is required. I am trying to understand

I want to store data in a large array with _mm256_stream_si256() called in a loop. As I understood, a memory fence is then needed to make these changes visible to other threads. The description of _mm_sfence() says Perform a serializing operation on all store-to-memory instructions that were issued prior to this instruction. Guarantees that every store instruction that precedes, in program order, is globally visible before any store instruction which follows the fence in program order. But will my recent stores of the current thread be visible to subsequent load instructions too (in the other

Like many other people, I've always been confused by volatile reads/writes and fences. So now I'm trying to fully understand what these do. So, a volatile read is supposed to (1) exhibit acquire-semantics and (2) guarantee that the value read is fresh, i.e., it is not a cached value. Let's focus on (2). Now, I've read that, if you want to perform a volatile read, you should introduce an acquire fence (or a full fence) after the read, like this: int local = shared; Thread.MemoryBarrier(); How exactly does this prevent the read operation from using a previously cached value? According to the