Hi guys,
First, I want to appologize for the tone I've used in some of my mails
and on IRC. I had a bad day yesturday, and just was too much heated.
Sorry for that, Trustin and David.
Now that I have had a good night sleep, let's address the problem a
little bit more quietly.
Dmitry concern is important, but instead of devising about solution
directly, may be should we list all the possible configuration elements
we need to protect. When we have this list, we may pick the best
possible solution to guarantee this protection we are talking about.
Niklas had an important point too : is it really a problem, when the
users is supposed to be aware of some potential problems, and use its
own synchroniation to be thread safe. Unless we state about this point,
we may simply discuss for nothing :)
Assuming that we need to get a fix done, then we have other elements to
take care of :
- simplicity
- efficiency
- performance
We have 3 possible options depending on the kind of data we want to
protect :
1) use synchronization
2) use volatile
3) use AtomicXXX
I _don't_ think we should only use only one of those thee guys to
protect all the configuration elements, because it would be overkilling.
However, I would suggest we go to a correct solution first, and when
it's proven to work well, we might improve this correct solution using
less intrusive solutions.
In any case, synchronizing would be correct in all cases, even if it
sounds heavy. AtomicXXX construction is proven to be correct and accepted.
Let's talk a bit about volatile, to summarize why I don't really like it
a lot, as a first class solution :
Volatile works, to a certain extents, but have a fewer advantage. It is
a 'weaker synchronization', don't protect against atomic operations, and
may, to some extent, be more costly than a synchronized method (yes,
really, if you have many threads reading the volatile value, but this is
not such a big deal).
Volatile was introduced as a reserved keyword in JAVA since its
inception, just because Java is multi-threaded from the origin. Volatile
just came from the C++ language, where the language designers found it
useful to protect the T (multi-threaded) programs against the optimizer,
which can affect a registry to a variable (for performance reasons). But
the problem is that the Java Memory Model(JMM) was totally broken (well,
in 99,9% of the case, it's ok) until it has been fixed in Java 5 (and it
tooks 3 years to get it fixed !!!).
In the first and second version of the Java Language Specification, for
instance, long and double weren't protected as atomic variable by the
volatile keyword. In the third version, long and double are now
protected, at will :
http://java.sun.com/docs/books/jls/third_edition/html/memory.html#61803,
17.7 :
"Some implementations may find it convenient to divide a single write
action on a 64-bit long or double value into two write actions on
adjacent 32 bit values. For efficiency's sake, this behavior is
implementation specific; Java virtual machines are free to perform
writes to long and double values atomically or in two parts."
This may be a real problem if you don't use the SUN JVM (either you like
IBM JVM, Jrockit JVM which comes with BEA WebLogic, MacOSX JVM), unless
you double check that those JVM complies with this proposal ('may' is
important ).
Volatile don't protect against atomic operation, like ++ or such. This
has to be known, and considered. Volatile just guarantee the visibility,
not the atomicity. In some case, this might not be enough.
Anyway, there are some solid and valid usage for volatile, but those
usage are pretty limited to a small set of patterns
'http://www.ibm.com/developerworks/java/library/j-jtp06197.html). It
should not ba considered as a generic solution to all the
synchronization issues.
Last, not least, I would voice my opinion that as volatile is not a very
well known keyword, and that its semantic is not known by many, it would
be better to keep away from it for clarity sake. I understand that MINA
is a framework, and that what happens inside MINA just don't need to be
exposed to users, but I would like the MINA developpers to keep in mind
that our current users might become our future committers, and the more
complex the code will be, the more sophisticated the code will be, the
higher the entry gap will be for new committers.
"Write code for the average programmer" is one of the most important
rule to follow, because maintainers are generally "average programmers"
compared to the initial developpers (well, they are supposed to be,
which is obviously not true...). If the code is complex to understand,
and use complex and not well known constructions or pattern, then there
are good chances that the code will not evolved in the right direction
when the MINA founders will fly away...
That being said, I'm not against volatile usage, I'm just against
weaving it as the way to solve the problem we have.
Thanks for listening my long (not protected by volatile) and dire rant ;)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
