Pre-Proposal: Linguistic support for locks

[Jeremy Manson]

I'm not sure about this.  I believe that locks are being used as a
discussion proxy for any object that  lives longer than the try scope,
but needs to be opened and closed.

For example (all taken from a random sampling of real code), you might
have a logger that logs messages at the beginning and ending of the
block scope.  You might want to swap out your existing logger so that
it has different logging properties during the block scope.  You might
have a reference counter that is bumped and then reset.  You might
have a method that takes a Disposable resource as a parameter, but
needs to close the resource at the end.  You might have a cache with a
pinning strategy, and want to pin and unpin the item in the cache
during the block scope.

You can do these things with try / finally, but I think that
underlying this discussion is the principle that no one really likes
using try / finally for this pattern.  It's a construct that sadly
lends itself to cut-and-paste code -- you always have to put the
finally block in and call the dispose() method (or equivalent).

Jeremy

On Sun, Mar 8, 2009 at 10:20 AM, Joshua Bloch <jjb at google.com> wrote:
> 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
>>
>>
>
>