Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

False Sharing and Atomic Variables

When different variables are inside the same cache line, you can experience False Sharing, which means that even if two different threads (running on different cores) are accessing two different variables, if those two variables reside in the same cache line, you will have performance hit, as each time cache coherence will be triggered.

Now say those variables are atomic variables (By atomic I mean variables which introduce a memory fence, such as the atomic<t> of C++), will false sharing matter there, or it does not matter if atomic variables are in the same cache line or not, as supposedly they will introduce cache coherence anyway. In other words, will putting atomic variables in the same cache line make application slower than not putting them in the same cache line?

like image 674
pythonic Avatar asked Apr 13 '12 15:04

pythonic


People also ask

What does happen during false sharing?

False sharing degrades performance when all of the following conditions occur: Shared data is modified by multiple threads. Multiple threads modify data within the same cache line. Data is modified very frequently (as in a tight loop)

How do you fix false sharing issues?

In general, false sharing can be reduced using the following techniques: Make use of private or threadprivate data as much as possible. Use the compiler's optimization features to eliminate memory loads and stores. Pad data structures so that each thread's data resides on a different cache line.

What is false sharing and true sharing?

As I understand it, true sharing refers to the problem of multiple cores frequently writing to the same shared variable, while false sharing refers to multiple cores writing to different variables that are on the same cache line.

What is false sharing in the context of multi threading?

"false sharing" is something that happens in (some) cache systems when two threads (or rather two cores) writes to two different variables that belongs to the same cache line.


2 Answers

A clarification: for negative consequences at least some accesses to "falsely shared" variables should be writes. If writes are rare, performance impact of false sharing is rather negligible; the more writes (and so cache line invalidate messages) the worse performance.

Even with atomics, cache line sharing (either false or true) still matters. Look for some evidence here: http://www.1024cores.net/home/lock-free-algorithms/first-things-first. Thus, the answer is - yes, placing atomic variables used by different threads to the same cache line may make application slower compared to placing them to two different lines. However, I think it will be mostly unnoticed, unless the app spends a significant portion of its time updating these atomic variables.

like image 179
Alexey Kukanov Avatar answered Oct 03 '22 12:10

Alexey Kukanov


If you use atomic variables with the strongest consistency requirements, a full memory barrier, the effect of false sharing will probably not be noticeable. For such an access the performance of an atomic operation is basically limited by the memory access latency. So things are slow anyhow, I don't think they would get much slower in the presence of false sharing.

If you have other less intrusive memory orderings the performance hit by the atomics itself may be less, and so the impact of false sharing might be significant.

In total, I would first look at the performance of the atomic operation itself before worrying about false sharing for such operations.

like image 35
Jens Gustedt Avatar answered Oct 03 '22 12:10

Jens Gustedt