[concurrency-interest] Assignment of references atomic?

Ryan LeCompte ryan.lecompte at pangonetworks.com
Wed Oct 12 10:02:17 EDT 2005

I'm not sure I completely understood your last reason for *not* using
volatile. Forgetting about the code sample from earlier, I basically have
two variables.. one is a primitive (boolean) and the other is a regular
Object reference. Is it safe to declare both of these as volatile? I want to
ensure that other threads see the most recent values of these two variables.


-----Original Message-----
From: Tim Peierls [mailto:tim at peierls.net] 
Sent: Wednesday, October 12, 2005 9:58 AM
To: Ryan LeCompte
Cc: concurrency-interest at altair.cs.oswego.edu
Subject: Re: [concurrency-interest] Assignment of references atomic?

Ryan LeCompte wrote:
> Thank you for the lengthy response. This particular part of the code can
tolerate stale values
> that are returned from the getObject() method. However, I want to be able
to rely on the fact
> that the getObject() method will EVENTUALLY return a recent update to the
this.object (o)
> field. Am I safe to make that assumption? Or is it possible for the JVM to
always return a
> stale value even if the value gets updated one more time?

That assumption is not safe. No matter how many times a thread updates the
variable, other threads 
will see arbitrarily stale values.

> What about declaring the variable volatile?

Ah! Yes, volatile *does* work, and is the most appropriate mechanism. I
should have mentioned that 
first, sorry.

The only reason you might *not* want to use a volatile is if there is a
class invariant involving 
more than one field, including the object field. I saw the use of a variable
named someCondition 
and assumed this was the case.


More information about the Concurrency-interest mailing list