Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Thread visibility among one process

I'm reading the book Crack Code Interview recently, but there's one paragraph confusing me a lot on page 257:

A thread is a particular execution path of a process; when one thread modifies a process resource, the change is immediately visible to sibling threads.

IIRC, if one thread make a change to a variable, the change will firstly save in the CPU cache (say, L1 cache), and will not guarantee to synchronize to other threads unless the variable is declared as volatile.

Am I right?

like image 515
WoooHaaaa Avatar asked Apr 28 '13 05:04

WoooHaaaa


1 Answers

Nope, you're wrong. But this is a very common misunderstanding.

Every modern multi-core CPU has hardware cache coherence. The L1, and similar caches, are invisible. CPU caches like the L1 cache have nothing to do with memory visibility.

Changes are visible immediately when a thread modifies a process resource. The issue is optimizations that cause process resources not to be modified in precisely the order the code specifies.

If your code has k = j; i = 4; if (j == 2) foo(); an optimizer might see that your first assignment reads the value of j. So it might not bother reading it again when you compare it to 2 since it "knows" that it can't have changed. However, another thread might have changed it. So optimizations of some kinds need to be disabled when synchronization between threads is required. That's what things like volatile do.

If compilers and CPUs made no optimizations and executed a program precisely as it was written, volatile would never be needed. Memory visibility is about optimizations in code (some done by the compiler, some by the CPU), not caches.

like image 157
David Schwartz Avatar answered Sep 23 '22 00:09

David Schwartz