CPU Cache Coherence + Java Concurrency

[@COFFEEWITHJAVA]

Thank you Jacob for wonderful lessons. I feel nobody can rip apart the Core no matter how many topplings/mountings is being done by Spring.

[@JakobJenkov]

Thanks - and you are welcome! :-) The more experience I get, the more I prefer small, narrowly targeted toolkits over big all-encompassing one-stop-solution frameworks. I know not all developers share this preference - but some do.

[@COFFEEWITHJAVA]

@@JakobJenkov That's cool. I share the same passion as yours. I truly strive to make a balance between retaining core yet diving further into Spring. I love Java. 👍. The cache coherence diagram concept is amazing 👏.

[@shubhamagarwal1434]

God of Concurency..i have bene flowing you since my 2014 when you used to write blog post only...by going through your post i attend interview like a LION when they ask mutithreading qns.....Thanks a Lot form 10+ yrs exp guy from BLR,India.

[@JakobJenkov]

Thanks :-)

[@shaileshkumar-df3zd]

Dear Sir, it would be very helpful if you upload some design pattern video with some real time example , Thanks Shailesh

[@JakobJenkov]

What do you mean by "real time example" ?

[@arihantpatil2725]

@@JakobJenkov I think the implication is "real world examples"

[@sublime_47]

Thanks for your work, Jacob. But I don't understand, if other caches can see the cached values of the variables, why are we using volatile? Or does cache coherence only work when we are using volatile variables (or a synchronized block)? this confused me a bit because I thought volatile was used to avoid caching variables, and now I see that other caches are seeing these changes. It will be great if you can help me understand this part)

[@christopherrowley7506]

I think it's because the cache coherence isn't a guarantee. It just happens on occasion to speed up processing. So it COULD be shared between caches, or it may wait and flush to main memory. That would be my guess. Jakob seems to be good at replying so I'm sure he'll give you the more exact answer soon.

[@JakobJenkov]

Only when you use volatile, synchronized blocks, or other concurrency constructs such as Lock or the many AtomicXYZ classes, can you be sure that a variable value is flushed from the CPU registers to main memory - which will first cause them to be flushed to the CPU cache. Without volatile you don't know when a variable will be flushed from a CPU register towards main memory.

[@JakobJenkov]

As far as I know, cache coherence mechanisms do give a guarantee about cross cache visibility. Otherwise they would not be super useful. But a variable can linger in a CPU register for quite a long time - where it is NOT visible to other threads or CPU caches elsewhere.

[@sublime_47]

@@JakobJenkov Thanks again , now i can resume watching videos with better understanding of this one)

[@sergeibatiuk3468]

@@JakobJenkov This may also be architecture-dependent which is not what JVM is about

[@smitmandavia5044]

Thank you so much for the amazing content that you create! Its super detailed and super helpful.

[@smitmandavia5044]

Thanks for the entire playlist on concurrency.

[@JakobJenkov]

Wow! Thank you very much! ... I've had a busy week so I didn't see your comment until now !! :-)

[@JakobJenkov]

You are very welcome ! :-)

[@sujeetbadnale9441]

Hey Jacob, Brother you are blessed. I have seen your videos on same topic, however you made a dedicated video this concept. Thank you for that hardwork and thank you for giving us for free. God Bless You Heavily. 😇

[@JakobJenkov]

Thank you very much ! ... I am happy that my video was useful for you ! :-)

[@欢肖-n9d]

Thank you for your great job.But i also have problem about CPU cache in video. “ The hardware may choose only to flush the variables into the CPU cache ” , The CPU cache in this statement means L3 cache or L1, L2 and L3 cache ?

[@JakobJenkov]

Probably L1, L2 and L3 cache in total. I think it depends on the concrete hardware what it might do (not 100% sure !).

[@shankar7435]

Feeling lucky to fond your videos. Thanks a lot.

[@JakobJenkov]

Happy to hear that 😊

[@phucosg]

Thank you very much for another great series on Java concurrency

[@JakobJenkov]

You are welcome! And thank you for your feedback! :-)

[@sergeibatiuk3468]

L2 cache should probably span 2 CPU cores as well as 2 L1 caches

[@JakobJenkov]

Possibly.... hardware platforms are not all uniform . But that is actually not super important in practice.

[@pveentjer]

This still isn't correct. Memory transfers are done at the unit of a cache line (typically 64 bytes). When there is a load or store, the cacheline first needs to be obtained. It could be that it needs to be invalidated at other CPUs but it could also mean it is pulled from main memory. Once the cache line is in the right state, the cache line doesn't need to leave the cache of the CPU at all as long as there is enough space and no other CPU is asking for it. Even when another CPU ask for it, depending on the cache coherence algorithm, dirty cachelines don't need to be propagates to main memory (e.g MOESI). So imagine you would continuously update a limited set of volatile variables on a single CPU, the corresponding cache lines can remain in the cache of the CPU and never need to be propagates to main memory. So in short: flusing variables to main memory as consequence of a synchronized block or volatile is a fallacy. Effectively there is not even a difference between a plain write or a volatile write at the level of cache interaction. Cache coherence ensure that CPUs do not see outdated cache lines. And all modern CPUs have coherent caches. If you want to get a better answer, send me a message on twitter.com/PeterVeentjer.

[@JakobJenkov]

I don't say anything in this video that is not in line with what you are saying here. I mention later that thr hardware may choose not to write the data from the caches to main memory at all.