lucene-dev mailing list archives

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

About Simons mail: http://blogs.sun.com/dave/entry/java_util_concurrent_reentrantlock_vs

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 @ http://s.apache.org/ze for more details about the proposed lockless IndexWriter/NRT
functionality.

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

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de

> -----Original Message-----
> From: Simon Willnauer [mailto:simon.willnauer@googlemail.com]
> Sent: Sunday, June 13, 2010 4:23 PM
> To: dev@lucene.apache.org
> 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 <edwardd@wolfram.com>
> 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: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message