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

David Holmes davidcholmes at aapt.net.au
Thu May 14 07:27:27 EDT 2009


The cache-flushing model as used by the old Java Memory Model was a simple
conceptual model to explain the basic concepts, but was inadequate. The new
Java Memory Model does not use that model. In practice there are few
remaining architectures where actual cache flushing is needed. On main
platforms write-through caches are often used.

This is a subject that has been discussed many, many times and the best
resource is to check the mailing list archives of the Java Memory Model
mailing list:

https://mailman.cs.umd.edu/mailman/listinfo/javamemorymodel-discussion

David Holmes
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Yechiel
Feffer
  Sent: Thursday, 14 May 2009 9:16 PM
  To: concurrency-interest at cs.oswego.edu
  Subject: [concurrency-interest] a question regarding volatile &
cacheflushing/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?


  Regards,

  Yechiel Fefer






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


More information about the Concurrency-interest mailing list