Ceki, Thanks. Your points are well taken. I guess I err on the side of caution. Plus most of the synchronized code in PluginRegistry is not as simple as your example or the Category code (which might be a problem I should review).
I made the changes in PluginRegistry, but I still need to test it out. I like the use of ReaderWriterLock. It is going to be better than the synchronized blocks I had before. Thanks for adding it! I'm surprised that a concurrency library is not part of Commons. Or maybe I just missed it? -Mark > -----Original Message----- > From: Ceki Gülcü [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 24, 2003 6:04 AM > To: Log4J Developers List > Subject: Re: ReadWriterLock usage > > > At 09:16 PM 6/23/2003 -0700, you wrote: > >I was looking at the usage of the ReadWriterLock class the > Category code > >as an example for my similar modification to the PluginRegistry. > > > >Shouldn't all the releaseWriteLock() and releaseReadLock() calls be > >contained in finally blocks? Unless we are absolutely sure that an > >exception cannot be thrown in that code, it seems like a > good defensive > >coding style. Otherwise the lock counts could get out of > whack at some point. > > Hello Mark, > > Constraining all lock operations to try/finally block is certainly > safe. In the Category class where new ReaderWriterLock code was added, > there is one occasion where a try/finally block is used, namely within > the callAppenders method bacause the call to > appendLoopOnAppenders can throw > an exception upon appender failure. > > However, in the other methods, lock operations are not constrained to > a try/finally block because the probability of getting hit by > an exception is extremely low. > > Here is an example of what I mean > > void incrementFoo() { > lock.getWriteLock(); > foo++; > lock.releaseWriteLock(); > } > > The above code is safe because if we cannot assume to be able to > increment an integer variable safely, the situations is rather > hopeless anyway. The following version is formally safer but only in > theory. > > void incrementFoo() { > try { > lock.getWriteLock(); > foo++; > } finally { > lock.releaseWriteLock(); > } > } > > By the same token, if we cannot assume to safely add an > object to the array > of vectors, than the situation is near hopeless, and all attempts at > rescue are likely to be futile. That is why the other calls > manipulating locks are not placed within a try/catch block. > > I hope this answers the question, > > >-Mark > > -- > Ceki For log4j documentation consider "The complete log4j manual" > ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp > > > --------------------------------------------------------------------- > 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]
