Feedback and comments on ARM proposal

[Tim Peierls]

Neal Gafter wrote:

> You've avoided one problem by narrowing the applicability of the
>
construct.  Given your hopes (above), that is quite a drawback.
>

That was my initial reaction to the ARM proposal, but I now think the
applicability of the construct is as wide as it needs to be in practice.

When Josh writes that he hopes "the construct works for the great majority
of block-structured resources", I don't think he means that he expects to
suddenly uncover a forgotten trove of resources with a close() method. I
think he means that we want to make it easy for library writers and
maintainers to provide ARM support wherever it's really needed. I believe
that the current proposal achieves this goal; the coin-dev list has yet to
come up with an example where ARM support is both appropriate and difficult
to provide under the proposal.

Speaking of appropriateness (and moving to a new topic), a common response
to ARM is to be disappointed that it doesn't handle j.u.c.locks.Locks, to
the point where a second, separate quasi-proposal is floating around with
"protected" as a potential keyword to mark an automatic unlock()
construct. I think this particular enhancement is a bad idea.

Lock was added to handle some special cases that built-in synchronization
doesn't support, like non-block-structured locking, and most people
shouldn't use it. There's no sense in promoting a convenience construct for
an interface that most people shouldn't use, a convenience that wouldn't
even be useful most of the time for the few legitimate users of that
interface.

Getting a little OT: If you're using Lock.lock() and Lock.unlock()
exclusively now, unless you are using Conditions, you might as well just use
regular built-in synchronization. Your code will be easier to understand. If
you're using tryLock() or lockInterruptibly() then you really do want
try-finally. And even if you are using Conditions, you should use
try-finally to make it easier for people to follow your code -- using
Conditions correctly is hard enough without people burying details in the
sugar.

Moreover, apart from non-block-structured locking, which is really for
experts only, I have yet to see Lock/Condition (or notify/wait, for that
matter) used in a way that couldn't be improved by replacing it with a
higher-level j.u.c abstraction like Semaphore, CountDownLatch, or
CyclicBarrier/Phaser.

--tim


On Mon, Mar 9, 2009 at 11:25 PM, Neal Gafter <neal at gafter.com> wrote:

> On the one hand, you say
>
> On Mon, Mar 9, 2009 at 4:24 PM, Joshua Bloch <jjb at google.com> wrote:
> > The proposed construct *was*  designed to go beyond IO-related
> "Closeable"
> > resources.  ...  I sincerely hope the construct works for the great
> > majority of block-structured resources, whether or not their
> > close/dispose/release/whatever method is defined to throw an exception.
>
> And then...
>
> > At this point, I think only one name will be supported (close), so the
> > problem goes away.
>
> You've avoided one problem by narrowing the applicability of the
> construct.  Given your hopes (above), that is quite a drawback.