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

Joe Bowbeer joe.bowbeer at gmail.com
Thu May 14 16:29:06 EDT 2009

I assume you a mean static member variable rather than a static value.  (If
its value truly were static, you should declare the field as "final".)

In the worst case, without volatile, the compiler might reorder the read
and/or write accesses to the static field, rendering it useless as a
decision variable.

In practice, the compiler probably isn't that smart, and there's probably
too much other synchronization in the way, limiting the extent to which the
compiler can relocate these accesses.

I would declare it volatile and document why.


On Thu, May 14, 2009 at 12:51 PM, Paulo Levi wrote:

> I have a small question regarding static values. Do they have to be marked
> volatile in order that the new value is visible, or does the new value
> eventually get visible. Does volatile work the same for static values
> regarding multi-threaded visibility?
> The operation that I'm trying to short circuit is a simple boolean value
> test to shorten useless (but inoffensive) additional work, as in setting the
> (shared) value to false on a exception and then forgetting it. Instances
> will be used by many threads off course.
> I'm just going to mark the static value as volatile, but i'm curious.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090514/523478f9/attachment.html>

More information about the Concurrency-interest mailing list