lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Willnauer <>
Subject Re: Synchronized blocks?
Date Sun, 13 Jun 2010 14:22:44 GMT
Hi Edward,

I don't think we should take any action on replacing all synchronized
blocks with ReentrantLock.
In my opinion synchronized should still be preferred to ReentrantLocks
as intrinsic locks still have many advantages over explicit locks.
If you don't need any features not provided by intrinsic locking you
should stick to synchronized blocks. Almost everybody is familiar with
the notation, the concept is well known and they are less error-prone.

While there are significant throughput improvements in Java 5 for
explicit locks they more or less disappeared in Java 6. Actually it
might be even more likely that future improvements are done on
intrinsic locks rather than on explicit locks due to their build in
nature. One more thing about synchronized blocks is that they do
appear in thread dumps while explicit locks don't (actually in java 6
they do) which is a very important property in my eyes.

I still think that in certain locations we could use explicit locks so
keep your eyes open - replacing all synchronized blocks might not be a
good idea!


On Tue, Jun 8, 2010 at 4:37 AM, Edward Drapkin <> wrote:
> Hello all,
> I've been getting more acquainted with the source for lucene lately and have
> noticed that all contention points (that I've seen) are handled by
> synchronized blocks.
> Since Lucene now requires Java 5, my question is this: is there any
> compelling reason to not dig through the code and replace uses of
> synchronized with ReentrantReadWriteLocks, especially as the performance of
> that locking mechanism (where behavior is the same) is much better in Java
> 5? While the sheer throughput difference in Java 6 may be lower, the ability
> to have multiple concurrent readers without contention ought to yield across
> the board performance improvements of some significance.
> As I am digging through (most of) the code anyway, I would have no problem
> doing this myself and "upgrading" the locking mechanisms everywhere, but
> seeing as it is an enormous venture, I wanted to make sure that it would be
> okay to do before investing the time and that an enormous patch wouldn't
> immediately be rejected.  Also, if this is okay to do, how should I present
> the patch?  I would think that an enormous patch touching dozens (if not
> well over a hundred?) of files isn't preferable at all, but I can do that
> too!
> Thanks,
> Eddie
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message