AutoLock

[Joshua Bloch]

Folks,

This (locking) was an explicit non-goal of the JSR.  If we were in favor of
supporting it, I'd recommend:

    protected (lock) {
        ... code ...
    }

But Doug and other concurrency experts say that we shouldn't be encouraging
people to use locks directly.

    Josh

On Sun, Feb 27, 2011 at 2:42 PM, David Holmes <David.Holmes at oracle.com>wrote:

> Hi Heinz,
>
> One slight glitch here is that, as I recall (and I'd like Joe to confirm
> as I can't find anything in writing) they updated the spec to disallow
> simple expressions, so you need to use something slightly more verbose
> that introduces a local variable to refer to the Lock.
>
> Also as I understand it escape-analysis is only used by the server
> compiler, so we can not rely on having it to get rid of the object
> creation overhead. As indicated in the other threads on coin-dev there
> are ways to do this without having to introduce a new object as a
> wrapper - but they introduce their own overheads.
>
> By the way, the "whopping 553 classes" that implement AuoCloseable comes
> about due to Closeable being retrofitted to also be AutoCloseable. No
> big surprise that these are primarily (all?) I/O related classes.
>
> Cheers,
> David Holmes
>
>
> Dr Heinz M. Kabutz said the following on 02/28/11 05:30:
> > Hi,
> >
> > Brian told me about the discussion going on here on coin-dev.  I
> > published a newsletter today on the new Java 7 try-with-resource
> > construct and how we could use it for automatically unlocking.  By
> > combining it with static imports, we can write the following code:
> >
> >     try (lock(lock)) {
> >       printLockStatus();
> >     }
> >
> > Instead of the current more verbose
> >
> >     lock.lock();
> >     try {
> >       printLockStatus();
> >     } finally {
> >       lock.unlock();
> >     }
> >
> > In my newsletter, I expressed the same concern as Neal, that
> > constructing objects, and in fact encouraging people to do this in
> > performance critical code, could be a killer for this idea.
> >
> > However, initial tests indicate that escape analysis actually does a
> > nice job of eliminating the cost of the object construction.  These are
> > just completely basic initial tests and are quite possibly flawed.
> > However, with the default escape analysis turned on, my try (lock(lock))
> > code did not cause any objects to be created, even though I called it
> > 1_000_000_000 times.
> >
> > When I turned off escape analysis, it constructed about 30GB of objects.
> >
> > As I said, I have not tested this properly, just an initial
> investigation.
> >
> > Here is the link to my article:
> > http://www.javaspecialists.eu/archive/Issue190.html
> >
> > Regards
> >
> > Heinz
>
>