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: [email protected] > -----Original Message----- > From: Simon Willnauer [mailto:[email protected]] > Sent: Sunday, June 13, 2010 4:23 PM > To: [email protected] > 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 <[email protected]> > 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: [email protected] For > > additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
