Feedback and comments on ARM proposal

[Tim Peierls]

On Tue, Mar 10, 2009 at 11:51 AM, Peter Mount <peter at retep.org.uk> wrote:

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

http://jcip.net -- see especially Chapter 5 and Section 13.4.



> However what you cannot do with synchronization is ReentrantReadWriteLock
>> ...
>
>
I think most cases where many-reader-one-writer access is needed are best
expressed using higher-level constructs (that might use RRWL in the
plumbing). Anything else I would classify as an advanced application, where
the explicit try-finally is better than implicit behavior.



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

Sounds like you want a higher-level concurrency utility. You don't want your
game developer to have to work with a bunch of Locks and Conditions with a
complicated pattern of use; you want them encapsulated nicely. If you can't
find the right utility in j.u.c, write your own. If you can't write your
own, get an expert to do it for you.

My point is not that it is never appropriate to use a Lock but that Lock is
geared towards experts, the people who build stuff that application-level
developers use. But experts make more diverse use of Lock than is supported
by the "protected" construct.



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

Lock offers features that built-in synchronization doesn't, most of which
don't work well with the "protected" construct, but it's not at all clear
that Lock outperforms synchronized, even under heavy contention on
multiprocessor machines.

--tim