On Sep 1, 2006, at 9:50 AM, Claudio Corsi wrote:
Curt,
I've read that using notifyAll compared to notify causes a
performance degradation. Have you run any performance tests
comparing this change?
--Claudio
I did not do any performance tests on the change. The change is in
the Scheduler class which was developed for use by the configuration
file monitors that would reconfigure log4j when a change in the
configuration file is detected. In this case, correctness is much
more important than performance. The scheduler has been observed to
fail tests on Gump and the use of notify() when notifyAll() is needed
might have been responsible. I was hoping that the change would
clean up the Gump failures but it appears that it has not.
From section 3.2.4 (pg 192) of "Concurrent Programming in Java,
Second Edition":
In open, extensible designs, the conditions under which notify
apply are rather special and fragile. The use of notify, and
optimizations of guarded conditions more generally, are common
sources of error. As a general design tactic, it is a better idea
to isolate uses of notify to concurrency control utility classes
that can be heavily optimized and carefully reviewed and tested.
Getting something like org.apache.log4j.Scheduler done right is
hard. If we were targeting JDK 1.5, it would be a obvious to drop
that class and use java.util.concurrent.ScheduledExecutorServer. If
we were to press on with log4j 1.3 and in light of the on-going test
failures on Gump, we would need to consider either rolling back
FileWatchdog to the log4j 1.2 implementation or take a hard look at
org.apache.log4j.Scheduler.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
