On 2/8/2011 9:22 AM, Patricia Shanahan wrote:
For shared counters, there is no need for an explicit MyClassName.class
reference. All I did was make the get-and-increment a static synchronized method
in the same class in which the counter itself is a static field.
A static synchronized method is equivalently doing synchronized(
MyBaseClass.class ) around the method definition. Glad you got it straightened
out. Thanks for your work on these things!
Gregg
Doing local counters per class is fine, as long as every use of a single counter
synchronizes on the same object.
The best solution is to make these counters AtomicInteger or AtomicLong. That
builds the concurrency control into the counter itself, eliminating the
possibility of synchronization errors. I eagerly await the outcome of the "drop
1.4" vote.
Patricia
Gregg Wonderly wrote:
I think that there is a case either way. Some designs may, in fact want
subclasses to share separate counters. Using the explicit MyClassName.class
reference will create the shared lock for the super class and all sub classes.
More often than not, I've used this when I wanted the subclasses to stand alone.
Gregg Wonderly
On 2/7/2011 10:00 PM, Patricia Shanahan wrote:
I found a bad synchronization idiom in a couple of the QA test programs for
outrigger. I've done what I can to grep for it, but be alert in case it shows up
in code you are reading.
A non-final class needs to assign a unique number to each object of the class,
or any of its direct or indirect subclasses:
// Declared in the class
private static int nextID=0;
// Inside a constructor, or a method called from the constructor
synchronized(getClass()){
id = nextID++;
}
The synchronization is ineffective, because getClass() can return different
Class objects in a non-final class' constructor.
Patricia
