[concurrency-interest] Assignment of references atomic?
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.
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
> 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
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
and assumed this was the case.
More information about the Concurrency-interest