At 09:16 PM 6/23/2003 -0700, you wrote:
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(); }
Wouldn't this variable be best defined as "volatile" ?
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.
In my experience, and I have only been doing high volume server apps for about four years now, you can never rely on theory. Always err on the side of caution.
Also, the ReaderWriterLock is a nice thing in theory, but you need to take a look at what the main purpose of the class is. If it is to be read often, then making it read-only after initialization is the best approach. You only have to synchronize the init code, and you don't have to worry about reading. If the class is mainly volatile (i.e. a lot of writes) then your read/write lock will end up behaving like a Mutex, which is much easier to write and debug.
As to adding objects to arrays of vectors, then may I remind you that some collections will bork on "null" objects?
I personally have learned that if I think I am smarter than what should be theorhetically OK, some runtime condition always proves my ignorance. Even then, I still run into issues that folks far wiser than I who use the class differently uncover and fix.
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]
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
