RFR: 8077846: improve locking strategy for readConfiguration(), reset(), and initializeGlobalHandlers()

Daniel Fuchs daniel.fuchs at oracle.com
Thu Apr 30 14:42:01 UTC 2015

On 28/04/15 17:46, Peter Levart wrote:
> On 04/28/2015 04:57 PM, Daniel Fuchs wrote:
>>> Here's my attempt at simplifying this:
>>> http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.01/
>> LogManager can be subclassed, and subclasses may override reset() for
>> different purposes.
>> So I'm afraid the Cleaner thread still needs to call te public
>> reset() method. The same unfortunately applies to
>> readConfiguration().
>> best regards,
>> -- daniel
> Um, yes of course. This can be fixed:
> http://cr.openjdk.java.net/~plevart/misc/LogManager.synchronization/webrev.02/

Hi Peter,

Sorry for the late reply.

My gut feeling is that I dislike multi-state ints.
But I guess that's a matter of taste - so I could probably
overcome it ;-)

What makes me less happy is that I had managed to
remove the explicit synchronized() { } block in the
Cleaner thread - and I now see it's back.

Could we maybe keep the imminentDeath boolean and remove
the explicit locking in the Cleaner thread?

I mean... imminentDeath should be checked from within
the lock - before doing anything. But it does not need
to be set from within a locked section.

best regards,

-- daniel

> Regards, Peter

More information about the core-libs-dev mailing list