[concurrency-interest] RE: Synchronization of data readby multiple threads

David Holmes dholmes at dltech.com.au
Sun Oct 30 18:25:09 EST 2005

RE: [concurrency-interest] RE: Synchronization of data read by multiple

You seem to be missing some language fundamentals here. A final variable is
one that can never have its value change - it is immutable. And as Jeremy
informed you a final variable must always be definitely assigned otherwise
your code won't compile.

volatile variables are by definition mutable variables that change their
value. It is a compile time error to declare a variable both final and

You need to use volatile variables if the variable will be accessed by
multiple threads, at least one of which will update the value of the
variable, and there is no other synchronization controlling access to the

David Holmes

-----Original Message-----
From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Ryan
Sent: Monday, 31 October 2005 7:13 AM
To: concurrency-interest at altair.cs.oswego.edu
Subject: RE: [concurrency-interest] RE: Synchronization of data readby
multiple threads

  Okay, this sounds reasonable. So, if I make the variables "final" and they
are assigned their values in the constructor, then there is no need to make
them volatile if they are accessed by multiple threads, correct? Also, what
happens in the case of a boolean variable that is declared as a blank final?
If it gets a value assigned to it in the constructor, then it keeps that
value. Otherwise it just defaults to "false" as the final value, correct?


  -----Original Message-----
  From: Jeremy Manson [mailto:jmanson at cs.purdue.edu]
  Sent: Sunday, October 30, 2005 12:19 PM
  To: Ryan LeCompte
  Cc: concurrency-interest at altair.cs.oswego.edu
  Subject: Re: [concurrency-interest] RE: Synchronization of data read by
multiple threads

  Ryan LeCompte wrote:
  > Okay, that sounds fine. However, what about if the main thread (the
  > one that instantiated Test) continues to read values that were set in
  > the constructor? For example, if the main thread does:
  > t.isInstantiated() later on, will it continue to return the value
  > that was set in the constructor when Test was instantiated? Keep in
  > mind that in this particular scenario the values that the main thread
  > will read never change after being initially set in the constructor
  > of Test. There is no need for making the 'instantiated' variable
  > volatile in this case, right?

  Are you asking, "If one thread sets a field, and then later reads that
  field, do I have to do additional synchronization?"  The answer to that
  is no.  You don't need synchronization if you are only dealing with one

  By the way, if you are setting a field once, in the constructor, and
  then never changing it, then it is a good idea to make the field final.
    All reads of final fields return the correctly constructed value,
  without synchronization (unless a reference to the constructed object
  escapes the constructor, or you are using some weird custom
  deserialization protocols).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20051031/689987af/attachment.htm

More information about the Concurrency-interest mailing list