Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CADxc9BnHwQHA8DNxVxAtHd6v70TN2idrbtx4kqJHUPFNVs1PYQ@mail.gmail.com>
References: 
 <CAOiJXP53ykHNc+v=K8TTG3vHDFU+1LLaifm09H+4F4=1vUYFnA@mail.gmail.com>
	<CADxc9BnHwQHA8DNxVxAtHd6v70TN2idrbtx4kqJHUPFNVs1PYQ@mail.gmail.com>
Date: Thu, 13 Sep 2012 04:09:45 +0100
Message-ID: 
 <CAJRvFdrY0tYGdDBhoF5aOC98GPfM53WBc9o7ksWK2a_Mt=nCig@mail.gmail.com>
Subject: Re: Double Checked Locking - broken? working?
From: Mike Drob <mdrob@mdrob.com>
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=20cf307f3be0b52ece04c98ca3aa

--20cf307f3be0b52ece04c98ca3aa
Content-Type: text/plain; charset=ISO-8859-1

It's a private static field that never changes once we do the initial load.
The load looks idempotent, so I'm not sure it's worth the hassle of trying
to synchronize on it, or even do it lazily. Maybe somebody with more
history has seen that it is way more performance intensive than I give it
credit for, but I think we should just throw that part in a static block
and be done with it.

Alternatively, in the middle of that article, he suggests that if you have
a static singleton (which this appears to be) that you can throw it in
another class and the memory model will work out.

-Mike

On Thu, Sep 13, 2012 at 12:25 AM, Eric Newton <eric.newton@gmail.com> wrote:

> The article is correct. Just go ahead and simplify the code.
>
> -Eric
>
> On Wed, Sep 12, 2012 at 5:47 PM, David Medinets <david.medinets@gmail.com
> >wrote:
>
> > I see the following code in the Property class:
> >
> >   public static boolean isValidTablePropertyKey(String key) {
> >     if (validTableProperties == null) {
> >       synchronized (Property.class) {
> >         if (validTableProperties == null) {
> >           HashSet<String> tmp = new HashSet<String>();
> >           for (Property p : Property.values())
> >             if (!p.getType().equals(PropertyType.PREFIX) &&
> > p.getKey().startsWith(Property.TABLE_PREFIX.getKey()))
> >               tmp.add(p.getKey());
> >           validTableProperties = tmp;
> >         }
> >       }
> >     }
> >
> >     return validTableProperties.contains(key) ||
> > key.startsWith(Property.TABLE_CONSTRAINT_PREFIX.getKey())
> >         || key.startsWith(Property.TABLE_ITERATOR_PREFIX.getKey()) ||
> > key.startsWith(Property.TABLE_LOCALITY_GROUP_PREFIX.getKey());
> >   }
> >
> > However,
> > http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> > says that Double Check Locking does not work. Is there any reason to
> > believe that the article is incorrect? At the end of the article, it
> > recommends using volatile in Java 1.5 and above. Is there any reason
> > the code should not be changed to use the volatile technique?
> >
>

--20cf307f3be0b52ece04c98ca3aa--