This page is pretty clear on this subject: http://www.ibm.com/developerworks/java/library/j-praxis/pr50.html
In short: "If concurrency is important and you are not updating many variables, consider using volatile. If you are updating many variables, however, using volatile might be slower than using synchronization." Jeroen Brattinga On Wed, 2008-05-14 at 12:05 -0500, David M. Lloyd wrote: > On 05/14/2008 11:57 AM, Emmanuel Lecharny wrote: > > David M. Lloyd wrote: > >> On 05/14/2008 11:20 AM, Emmanuel Lecharny wrote: > >> > >>>> What I can tell at least though is that the session configuration > >>>> properties provided by IoService should be volatile, because they > >>>> are accessed in a different thread (I/O processor) almost always. > >>> Use synchronization, not volatile. it's too dangerous. When we are > >>> sure that it works fine, we _may_ switch to volatile. > >> > >> I don't understand this? Volatile isn't dangerous at all. It's > >> clearly defined and well-specified, and using it to make fields have > >> multi-thread visibility is a perfectly fine usage for them. > > The problem is not that volatile is dangerous by itself. Its semantic is > > really clear, assuming that you _know_ what you can and can't do. This > > is what scared me : mis-used of volatile. > > > > Before of using it, I would rather prefer that we expose the clear > > benefits we will get from it (and please, bring the numbers with you ;) > > before using it all over the code. > > Well, if you don't use it, then when someone calls a setter on the > property, the change may not be propagated to any other threads, meaning > that different threads could read different values for those properties. > If you do add volatile, then this doesn't happen - a change in one thread > is visible immediately thereafter from another thread. > > If you're suggesting that volatile isn't the appropriate solution to this > problem, I say that the burden is on you to explain why using the correct > tool for the job is not acceptable in this case, and what you hope to solve > (and be specific, FUD like "I'm afraid it will be misused" isn't good > enough) by using something more complex. We're talking about fields that > are accessed via simple getter and setter methods here. > > Again, you're saying "volatile is too dangerous", but you're not really > giving any specific reasons for this odd statement. > > > We are talking about minor improvement in this area. We have much bigger > > issues and much more important thinsg to deal with in MINA 2.0. > > Minor improvement? I thought we were talking about taking something that > doesn't work, and fixing it. > > - DML
