mov-store + mfence and xchg are both valid ways to implement a sequential-consistency store on x86. The implicit lock prefix on an xchg with memory makes it a full memory barrier, like all atomic RMW operations on x86. (x86’s memory-ordering rules essentially make that full-barrier effect the only option for any atomic RMW: it’s both … Read more
This code will demonstrate a torn read of a Decimal: using System; using System.Threading.Tasks; namespace ConsoleApp1 { class Program { void run() { Task.Run((Action) setter); Task.Run((Action) checker); Console.WriteLine(“Press <ENTER> to stop”); Console.ReadLine(); } void setter() { while (true) { d = VALUE1; d = VALUE2; } } void checker() { for (int count = 0;; … Read more
I’m a firm believer in that if you’re using interlocked to increment shared data, then you should use interlocked everywhere you access that shared data. Likewise, if you use insert you favorite synchronization primitive here to increment shared data, then you should use insert you favorite synchronization primitive here everywhere you access that shared data. … Read more
I’ve made a particular study of lock-free data structures in the last couple of years. I’ve read most of the papers in the field (there’s only about fourty or so – although only about ten or fifteen are any real use 🙂 AFAIK, a lock-free circular buffer has not been invented. The problem will be … Read more
re: your edit: But I do not want to use atomic variable. Why not? If it’s for performance reasons, use them with memory_order_relaxed and atomic_signal_fence(mo_whatever) to block compiler reordering without any runtime overhead other than the compiler barrier potentially blocking some compile-time optimizations, depending on the surrounding code. If it’s for some other reason, then … Read more
No, you don’t need barriers, but your code is broken anyway if readers and writers call these functions in different threads. Especially if a reader calls the read function in a loop. TL:DR: use C++11 std::atomic<long> m_value with return m_value++ in the increment and return m_value in the reader. That will give you sequential consistency … Read more
Current “lock-free” implementations follow the same pattern most of the time: read some state and make a copy of it* modify copy* do an interlocked operation retry if it fails (*optional: depends on the data structure/algorithm) The last bit is eerily similar to a spinlock. In fact, it is a basic spinlock. 🙂 I agree … Read more
No, volatile wouldn’t be helpful at all, and certainly not for this reason. It would just give that first read “acquire” semantics instead of effectively relaxed, but either way will compile to similar asm that runs a load instruction. if you get a dirty value from a CPU cache CPU caches are coherent, so anything … Read more
As of 1.53, boost provides a set of lock free data structures, including queues, stacks and single-producer/single-consumer queues (i.e. ring buffers).
I have looked for actual data for the past days, and found nothing. However, I did some research, which compares the cost of atomic ops with the costs of cache misses. The cost of the x86 LOCK prefix, (including lock cmpxchg for atomic CAS), before PentiumPro (as described in the doc), is a memory access … Read more