Trustin Lee wrote:
I don't know if somewhere you imply that, after one second, the
visibility problem will go away.
Isn't the working memory of the current thread synchronized whatever
monitor (lock) is acquired and released? So I thought acquiring
different locks doesn't matter. Please correct me if I am
misunderstanding JMM. If it's wrong, we definitely need to fix it.
My understanding is that this is not correct. You have to synchronize
with the _same_ lock, not any lock. Reread '3.1.3 Locking and
visibility' in 'Java Concurrency in Practice'. 3.1.1 describes what can
happen with stale data.
(sorry to quote that book again but it is very readable and I haven't
read the specs)
So for the case that we're talking about, I think that we agree that
we've found a potential problem. The question is not then IF it will be
a problem in practice or not, but rather HOW do we fix it. I believe
that making the selector volatile could fix the problem. IF I am correct
it should be done, unless another way to fix the problem is proposed.
I agree with you. Because volatile doesn't work very well in Java
1.4, what do we need to fix the problem in 1.0? Would using
synchronized block hurt performance?
Volatile works in Java 5 and 6 so that could do it for the branches
1.1.x and 2.0.
For 1.4, you will need to use the lock.
Would using synchronized block hurt performance?
My answer to that is 2 folds (11.1.2 Evaluating performance tradeoffs):
- First make it right, then make it fast - if it is not already fast enough.
- Measure, don't guess.
An alternative to synchronization would be to declare the selector
final. However this doesn't seems to be possible without some broader
refactoring.
_________________________________________________________________
Opret en personlig blog og del dine billeder på MSN Spaces:
http://spaces.msn.com/
