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

Ryan LeCompte Ryan.LeCompte at pangonetworks.com
Sun Oct 30 16:13:06 EST 2005


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?

Thanks,
Ryan

-----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 
thread.

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).

					Jeremy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20051030/bd53145d/attachment.htm


More information about the Concurrency-interest mailing list