Feedback and comments on ARM proposal (original) (raw)

Tim Peierls tim at peierls.net
Tue Mar 10 08:36:01 PDT 2009

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.

More information about the coin-dev mailing list