lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: Synchronized blocks?
Date Sun, 13 Jun 2010 16:25:20 GMT
Hi Edward,

About Simons mail:

And a second comment: Lucene Java Trunk will get a new IndexWriter internal implementation
that is almost completely lock-free through the second version of Near-Realtime-Search. Now
replacing all locks as you propose is just useless at this time. See Michael Busch's Talk
at BerlinBuzzwords @ for more details about the proposed lockless IndexWriter/NRT

I am in the same opinion like Simon: You should only use ReentrantLock if you need its special
features like tryLock() or the Read/Write Lock functionality. For all other cases ReentrantLock
adds extra verbosity and is more error-prone (you need try..finally block to ensure unlocking).


Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen

> -----Original Message-----
> From: Simon Willnauer []
> Sent: Sunday, June 13, 2010 4:23 PM
> To:
> Subject: Re: Synchronized blocks?
> 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!
> simon
> 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:

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

View raw message