[concurrency-interest] Significance of volatile for Objects
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.
> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Pavitar
> Sent: Friday, 7 March 2008 7:04 PM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] Significance of volatile for Objects
> 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.
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest