Feedback and comments on ARM proposal

[Peter Mount]

On Tue, Mar 10, 2009 at 3:36 PM, Tim Peierls <tim at peierls.net> wrote:

> Neal Gafter wrote:
>
>
> 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.


I think a lot of us have agreed that ARM in it's original proposal wouldn't
handle Locks, hence why there's now another proposal. I'm not certain about
the use of they protected keyword although it does make more sense than try
in this case.


>
> 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.


Do you have any references on why it shouldn't be used?


>
> 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.


For a simple Lock like RentrantLock then there's not much difference between
it and synchronization and I tend to use synchronization for that purpose.
However what you cannot do with synchronization is RentrantReadWriteLock
(i.e. multiple readers but one writer). Now as I (and others) have stated
before in other threads there's many reasons why having a construct for
Locks, specifically when you are dealing with a lot of copy and paste of the
finally clause (I'm keeping this short as it's already in the list archives
and this is a bit OT now).


>
>
> 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.


How about when you are providing access to multiple collections representing
game state where updates to those collections have to be atomic but reads
should not be blocking multiple threads on multiple cores when they are
accessed?

There's a lot of reasons where Locks are far superior than just
synchronization and moving to them have prooved to provide a serious
performance improvement in a heavily loaded multi-threaded environment.


>
>
> --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.
>
>


-- 
Peter Mount
e: peter at retep.org.uk
w: http://retep.org
Jabber/GTalk: peter at retep.org MSN: retep207 at hotmail.com