Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of
 SRS0=+BpZ4I=VF=wonderly.org=gregg@yourhostingaccount.com designates
 65.254.253.124 as permitted sender)
Message-ID: <4D51650C.1090909@wonderly.org>
Date: Tue, 08 Feb 2011 09:45:16 -0600
From: Gregg Wonderly <gregg@wonderly.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US;
 rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: river-dev@incubator.apache.org
CC: Patricia Shanahan <pats@acm.org>
Subject: Re: Bad idiom
References: <4D50BFE9.2040900@acm.org> <4D515A72.2020600@wonderly.org>
 <4D515FC1.50606@acm.org>
In-Reply-To: <4D515FC1.50606@acm.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Gregg Wonderly <gregg@wonderly.org>

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
>>>
>>>
>>>
>>>
>>
>>
>
>