volatile and caches question
vitalyd at gmail.com
Wed Jul 23 13:27:02 UTC 2014
Questions like this are probably best sent to concurrency-interest mailing
list (concurrency-interest at cs.oswego.edu).
Appropriate fences will be inserted even if single thread is
reading/writing a volatile. Assuming no false sharing of the cacheline
containing the volatile variable, no further memory transactions should
occur in this case (I.e. the core will have owned the line in exclusive
mode anyway and no other cores will be snooping it since nobody else is
With multiple readers single writer, readers will read from memory each
time. Assuming this cacheline stays in the cache, the read will be
serviced from one of the cache hierarchy levels. When a write occurs, the
reading cores will have the line invalidated and then snoop in the new
one. Generally, single writer multiple readers scales pretty well.
This is a high-level answer. If you want to dive into more details, I
suggest you drop this alias and use the concurrency interest one instead.
Sent from my phone
On Jul 23, 2014 9:06 AM, "Winnie JayClay" <winniejayclay at gmail.com> wrote:
> Say, if I have class with volatile variable, but only one thread operates
> on that variable (read and update it), will be memory flushed always on x86
> when the same thread read and write? What is the overhead and do you have
> any optimizations in JDK? Also if I have multiply threads which operate on
> single volatile variable: one writer and many readers and writer doesn't
> write too much, will be caches flushed every time readers access volatile
> varible and when write didn't write anything? I also thought to use normal
> non-final non-volatile variable and for writer thread create and invoke
> synchronized block somwhere after it will update varible to establish
> happens-before, i.e. just a synchronized block to flush caches for reader
> threads to pick up the latest value - by the way, is my understanding
> correct that if writer somewhere else invokes synchronized block which is
> not available for readers, will the readers get the latest value?
> Thanks for help, we work on HFT project in java, and performance is
> super-critical for us.
More information about the hotspot-dev