On Thu, 15 May 2008 16:08:58 +0900, Maarten Bosteels
<[EMAIL PROTECTED]> wrote:
On Thu, May 15, 2008 at 12:40 AM, 이희승 (Trustin Lee)
<[EMAIL PROTECTED]> wrote:
Yes. I was actually talking about the configuration properties which
meets
the two criteria.
Of course, counters, which were originally mentioned by Dmirty, should
use
AtomicIntegers.
So.. basically we were mixing up two kinds of properties in our
discussion.
To sum up:
* Use volatile for simple configuration properties
* Use AtomicInteger for other counters (except for performance
counters
which doesn't need to be accurate)
Does this make sense to you guys?
Yes, I think that makes sense. I just think that in general, we have
to be very careful when using volatile instead of locking.
For the reasons explained by Brian Goetz in the article mentioned
below, and also because it might be premature optimization
(or even no optimization at all).
The problem is we have so many properties which needs visibility
independent from each other. If we are going to use a lock, we will need
as many lock objects as the number of the properties, which is way too
much IMO. Or.. should we just return AtomicXYZ objects for all
properties? That's also a problem in terms of memory consumption and
encapsulation. Actually we might need some experiment here.
When I see a method like below, I wonder if that should be an atomic
operation ?
It's probably not really necessary, I don't know the code well enough to
judge.
public void increaseReadBytes(int increment) {
if (increment > 0) {
readBytes += increment;
lastReadTime = System.currentTimeMillis();
idleCountForBoth = 0;
idleCountForRead = 0;
}
}
readBytes += increment; should be atomic, and each assignment operations
should be visible to other threads (i.e. volatile is enough).
We can synchronize the whole operation (i.e. increaseReadBytes), but I
guess we won't get practical value from it as long as we don't expose an
explicit lock object for users.
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
