RFR: 8023168 - Cleanup LogManager class initialization and LogManager/LoggerContext relationship
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
>> from LoggerContext. AFAIR all these operations are synchronized on
> 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 ...
More information about the core-libs-dev