[concurrency-interest] a question regarding volatile & cache flushing/invalidating

Boehm, Hans hans.boehm at hp.com
Thu May 14 13:55:19 EDT 2009

This isn't really the way most modern hardware works.  The hardware already keeps the contents of caches basically consistent.  The problem is that memory operations may not become visible to other processors in the order in which they were issues, due to write buffers and other optimizations.  Volatile variables have to constrain this kind of reordering, but I don't think the cost has much to do with cache size.

This does mean that memory accesses will usually miss the cache (at least the local one) on the first access after the corresponding cache line was last updated by another processor.  In that weak sense caches are arguably less effective for multithreaded applications.


From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu] On Behalf Of Yechiel Feffer
Sent: Thursday, May 14, 2009 4:16 AM
To: concurrency-interest at cs.oswego.edu
Subject: [concurrency-interest] a question regarding volatile & cache flushing/invalidating

When a thread writes (assigns)  values to some non-volatile variables and then to a volatile variable, in order to make the non-volatile values visible to any other thread which reads the volatile variable, the writing thread has to flush all its dirty cache to main memory.
Is it a  correct assumption?
For the reading thread, when reading from the volatile variable it has to invalidate its (non-dirty) cache in order to retrieve the values of the non-volatile vars from main memory- in order to get the correct values of the non-volatiles when accessed after reading the volatile variable
Is it a correct assumption?

If so- doesn't it mean that

 1.  touching (writing to or reading from) volatile must be heavier when large caches are used or caches are fuller?
 2.  most multi threading programs are using ,explicitly or implicitly (via concurrent data structures) volatiles or locks. Does it mean that caches are becoming quite useless or even a burden in such systems?

Yechiel Fefer

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090514/e3468c85/attachment.html>

More information about the Concurrency-interest mailing list