RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship

Peter Levart peter.levart at gmail.com
Thu Sep 5 12:07:25 UTC 2013


On 09/05/2013 01:51 PM, Peter Levart wrote:
>>> ...almost all of them (except assignment to rootLogger) by 
>>> themselves ensure that the state mutations they make are published 
>>> to other threads, so if also *rootLogger* field was made volatile, 
>>> such double-checked locking would presumably not be broken.
>> Hmmm... By that I assume you mean the operations that access 
>> LogManager.rootLogger
>> from LoggerContext. AFAIR all these operations are synchronized on 
>> LoggerContext,
>
> The fact that they are synchronized on LoggerContext does not prevent 
> publication of rootLogger to them without write-read edge, since 
> writing to rootLogger field is performed without synchronization on 
> the same LoggerContext (it is performed with synchronization on the 
> LogManager instance)...

I should have been more precise:

The fact that they are synchronized on LoggerContext does not prevent 
publication of rootLogger to them without write-read edge, since writing 
to rootLogger field *can be* performed without synchronization on the 
same LoggerContext (it *can* be performed with synchronization on *just* 
the LogManager instance)... Such path is entry via 
LogManager.getLogManager() method ...

Peter




More information about the core-libs-dev mailing list