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]
