Well, don't we need to think about this issue from the MINA standpoint?
There's already plenty resources related with volatile and synchronized
keyword in the world.
MINA is a framework / library and is considereed to be thread-safe in most
cases, especially classes related with IoSession should be.
What Dmirty pointed out is that there's a potential visibility problem in
some of our configuration properties (including some performance counters?)
I don't think all properties should be exposed that precisely (especially
the statistical stuff). Moreover, so far, modification of any
configuration properties seems to be visible between user threads and I/O
processors due to some side effect of existing synchronization. However,
it is also true that we are depending on a tricky optimization which can
be fragile. Or it might have been broken already and it's just difficult
to reproduce. We actually don't know the cost of making those properties
volatile yet, but it is also true that we should value visibility than
performance built on top of inaccuracy.
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. Please let
us know if there's more.
On Thu, 15 May 2008 00:15:58 +0900, Emmanuel Lecharny
<[EMAIL PROTECTED]> wrote:
Jeroen Brattinga wrote:
Volatile means that a thread won't cache the (value of) a variable. So
your making sure that every thread sees updates on that variable.
More precisely, defining a variable as 'volatile' will forbid the JiT
compiler to optimize the code up to a point the variable is put into a
registry, but remains a plain java object. This is important because a
registry is *not* shared with other threads, which is potentially a
problem when another thread want to modify or read this variable.
The Volatile keyword DOES NOT provide protection against multiple
read/writes from different threads!
In fact, it does. But you can only protect the concurrent access for
simple get and set operations, not for any other kind of operation (like
i++, for instance, if i is declared as volatile).
Synchronization, locks or atomic
variables are still needed when this is an issue.
In any case, I would suggest we don't use volatile, as it masks some
semantic. Using a synchronized portion may cost slightly more time, but
at least, it is explicit, and helps coders to remember what's going on
with the protected variable.
For those who don't clearly understand the meaning of Volatile, and its
consequences, I would suggest the perfect book "Java concurrency in
practice", written by Brian Goetz, especially chapter 3.1.4.
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
