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

Tim Peierls tim at peierls.net
Tue Mar 10 09:46:04 PDT 2009

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

More information about the coin-dev mailing list