Pre-Proposal: Linguistic support for locks

[Joshua Bloch]

Folks,

I agree with Reinier on both counts; the proposal was specifically designed not
to address locks.  If people really want it to work for locks, I like the
idea of adding a new statement form:
    try (<lock-expr>) {
        <code>
    }

that desugars to:

Lock $lock = <lock-expr>;

     lock.lock();
     try {
         <code>
     } finally {
         lock.unlock();
     }

The new statement form looks exactly like a synchronized block, except that
the keyword synchronized is replaced by try; the desugaring comes straight
from the java.util.concurrent.locks.Lock page. The compiler would generate a
warning if you used an ordinary synchronized block  on an expression that is
assignment compatible with type Lock (because it's almost certainly a bug).
I don't think it's worth allowing multiple locks in a single statement.

This statement form is both simpler and less useful than the automatic
resource management statement.  A quick Google code search shows that
java.util.concurrent.locks.Lock usage is two orders of magnitude less common
that Java monitor lock usage. And I have no indication that people get it
wrong most of the time (as I do for "true resources"). Because I see this
functionality as largely orthogonal to that offered by the automatic
resource management statement, I think it belongs in a separate proposal.
 If Joe Darcy (who leads the project) thinks it's a good idea, I'm willing
to write that proposal.

                  Josh

P.S.  Two minor design alternatives present themselves:

   1. Use the protected keyword in place of try.
   2. If we do decide to use the try keyword, allow catch and finally for
   consistency (even though they have nothing to do with locking).

On Sun, Mar 8, 2009 at 1:00 AM, Reinier Zwitserloot <reinier at zwitserloot.com
> wrote:

> We're veering waaay offtopic here; the ARM proposal does not address
> locks. Period. Would everyone be happy if this was added in the 'major
> disadvantages' section?
>
> If locks are truly deemed crucial, or the consensus is that,
> eventhough evidently ARM-as-is can't do locks, people will try anyway
> and the resulting confusion must be avoided, I suggest that the ARM
> proposal is updated to do the right thing when an expression of type
> Lock shows up in a try ( lockShowsUpHere ) { code} block. Someone else
> proposed this before and I can't see any downside to this. It would be
> bad if, for every release, a bunch more types get special uniquely
> defined semantics in relation to the ARM expression, but that seems
> very unlikely. Nobody else has named a use-case that doesn't work in
> vanilla ARM yet seems likely to be abused, other than Lock, IIRC.
>
>  --Reinier Zwitserloot
>
>