이희승 (Trustin Lee) wrote:
Well, don't we need to think about this issue from the MINA standpoint?
I don't see that as an issue, as far as the properties are protexted
with correct synchronization.
MINA is a framework / library and is considereed to be thread-safe in
most cases, especially classes related with IoSession should be.
Yep, and it should be well protected. Synchonization is bullet proof.
Volatile is really weak, at least in a framework, as it does not protect
the users who don't understand the contract.
What Dmirty pointed out is that there's a potential visibility problem
in some of our configuration properties (including some performance
counters?)
We have to add some synchronization, then. Can be costly, but nothing
comes at no price those days ;)
I don't think all properties should be exposed that precisely
(especially the statistical stuff).
Anyway, 74,7% of all the statistics are proven to be wrong ...
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.
Uh? What does it means?
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.
Yeah, that might be an option.
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.
We should value correctness. Synchronization guarantee that if correctly
written. Volatile does not. Performance is irrelevant. If you want a
perfomant implementation on top of MINA, then disable the stats.
Watching destroys what is being watched (Schrodinger).
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.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
