RFR: 8077846: improve locking strategy for readConfiguration(), reset(), and initializeGlobalHandlers()
Mandy Chung
mandy.chung at oracle.com
Thu Apr 30 22:31:25 UTC 2015
On 04/30/2015 07:42 AM, Daniel Fuchs wrote:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8077846/webrev.00/
>> http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.02/
>>
I reviewed both of the above webrevs.
TestConfigurationLock.java
Copyright year should be 2015
TestConfigurationLock.properties
It would be good to delete all commented lines except the lines
relevant to the setting to make it obvious what the configuration is.
LogManager.java
I actually like having one state variable to describe the global handler
(re-)initialization that to me is a simplification. I couldn't
immediately match the constant names in following the code right away.
I read these states as:
STATE_UNINITIALIZED - request reinitialization or invalidate the
RootLogger
(called from readConfiguration and after reset)
STATE_INITIALIZED - reinitialization complete or error during
readConfiguration
STATE_INITIALIZING - global handlers are being initialized
Perhaps renaming the constant names to GLOBAL_HANDLERS_INVALIDATED etc
might help.
I'm less sure about shutdown and the global handlers can skip
reinitialization during shutdown and keeping it as separate variable
makes it more explicit. It may eliminate the configurationLock.lock()
in the Cleaner.run() method.
A minor point - I wonder if a private reset method taking a boolean
argument to indicate if the state change to STATE_INITIALIZED is
required would make it little easier to follow.
Mandy
More information about the core-libs-dev
mailing list