memory-barriers

When implementing a class intended to be thread-safe, should I include a memory barrier at the end of its constructor, in order to ensure that any internal structures have completed being initialized before they can be accessed? Or is it the responsibility of the consumer to insert the memory barrier before making the instance available to other threads? Simplified question : Is there a race hazard in the code below that could give erroneous behaviour due to the lack of a memory barrier between the initialization and the access of the thread-safe class? Or should the thread-safe class itself

I'm writing a multithreaded application in c++, where performance is critical. I need to use a lot of locking while copying small structures between threads, for this I have chosen to use spinlocks. I have done some research and speed testing on this and I found that most implementations are roughly equally fast: Microsofts CRITICAL_SECTION, with SpinCount set to 1000, scores about 140 time units Implementing this algorithm with Microsofts InterlockedCompareExchange scores about 95 time units Ive also tried to use some inline assembly with __asm {} using something like this code and it scores

Often in internet I find that LFENCE makes no sense in processors x86, ie it does nothing , so instead MFENCE we can absolutely painless to use SFENCE , because MFENCE = SFENCE + LFENCE = SFENCE + NOP = SFENCE . But if LFENCE does not make sense, then why we have four approaches to make Sequential Consistency in x86/x86_64: LOAD (without fence) and STORE + MFENCE LOAD (without fence) and LOCK XCHG MFENCE + LOAD and STORE (without fence) LOCK XADD ( 0 ) and STORE (without fence) Taken from here: http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html As well as performances from Herb Sutter on

I have found out that an x86 CPU have the following memory barriers instructions: mfence , lfence , and sfence . Does an x86 CPU only have these three memory barriers instructions, or are there more? sfence (SSE1) and mfence / lfence (SSE2) are the only instructions that are named for their memory fence/barrier functionality . Unless you're using NT loads or stores and/or WC memory, only mfence is needed for memory ordering. (Note that lfence on Intel CPUs is also a barrier for out-of-order execution, so it can serialize rdtsc , and is useful for Spectre mitigation to prevent speculative

I read the "Intel Optimization guide Guide For Intel Architecture". However, I still have no idea about when should I use _mm_sfence() _mm_lfence() _mm_mfence() Could anyone explain when these should be used when writing multi-threaded code? Caveat : I'm no expert in this. I'm still trying to learn this myself. But since no one has replied in the past two days, it seems experts on memory fence instructions are not plentiful. So here's my understanding ... Intel is a weakly-ordered memory system. That means your program may execute array[idx+1] = something idx++ but the change to idx may be

Can some of the load instructions be never globally visible due to store load forwarding ? To put it another way, if a load instruction gets its value from the store buffer, it never has to read from the cache. As it is generally stated that a load is globally visible when it reads from the L1D cache, the ones that do not read from the L1D should make it globally invisible. The concept of global visibility for loads is tricky, because a load doesn't modify the global state of memory, and other threads can't directly observe it. But once the dust settles after out-of-order / speculative