The interface IEnumerable<T> is not thread safe. See the documentation on http://msdn.microsoft.com/en-us/library/s793z9y2.aspx, which states: An enumerator remains valid as long as the collection remains unchanged. If changes are made to the collection, such as adding, modifying, or deleting elements, the enumerator is irrecoverably invalidated and its behavior is undefined. The enumerator does not have exclusive … Read more
x86 does not require alignment for a lock cmpxchg instruction to be atomic. However, alignment is necessary for good performance. This should be no surprise, backward compatibility means that software written with a manual from 14 years ago will still run on today’s processors. Modern CPUs even have a performance counter specifically for split-lock detection … Read more
Bottom line (TL;DR): LFENCE alone indeed seems useless for memory ordering, however it does not make SFENCE a substitute for MFENCE. The “arithmetic” logic in the question is not applicable. Here is an excerpt from Intel’s Software Developers Manual, volume 3, section 8.2.2 (the edition 325384-052US of September 2014), the same that I used in … Read more
The answer from the point of view of the language standard is very simple: none of them are “definitively automatically” atomic. First of all, it’s important to distinguish between two senses of “atomic”. One is atomic with respect to signals. This ensures, for instance, that when you do x = 5 on a sig_atomic_t, then … Read more
The GCC Wiki gives a very thorough and easy to understand explanation with code examples. (excerpt edited, and emphasis added) IMPORTANT: Upon re-reading the below quote copied from the GCC Wiki in the process of adding my own wording to the answer, I noticed that the quote is actually wrong. They got acquire and consume … Read more
As described in this closely related question that was mentioned in the comments, std::atomic<T> isn’t copy-constructible, nor copy-assignable. Object types that don’t have these properties cannot be used as elements of std::vector. However, it should be possible to create a wrapper around the std::atomic<T> element that is copy-constructible and copy-assignable. It will have to use … Read more
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
Per-element atomicity of vector load/store and gather/scatter?
The effect on g_qCount is the same, but what’s done is different. An OpenMP critical section is completely general – it can surround any arbitrary block of code. You pay for that generality, however, by incurring significant overhead every time a thread enters and exits the critical section (on top of the inherent cost of … Read more