[concurrency-interest] Significance of volatile for Objects

David Holmes dcholmes at optusnet.com.au
Fri Mar 7 04:58:28 EST 2008

It isn't a wrong usage per-se - you've just declared that a field of
reference type is volatile. This is no different to any other field type -
the meaning of volatile doesn't change.

The guarantees you get are as usual: a write to a volatile happens-before a
subsequent read of that written value. What that means for your program
depends on how the program reads/writes the volatile.

One idiom is to use the field as a "memory barrier" by doing:

data = data; // volatile read and write

to induce a happens-before ordering between code blocks. If I recall
correctly the Guava language (a variant of Java that disallows data races)
used this idiom.

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Pavitar
> Singh
> Sent: Friday, 7 March 2008 7:04 PM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] Significance of volatile for Objects
> Hi,
> If i have something like this:
> volatile Map data = new HashMap();
> then what are the gurantees provided by volatile.
> I know this is wrong usage of volatile. But i just wanted to know
> gurantees provided by volatile in case of Objects.
> Regards
> Pavitar
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list