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
