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

[Daniel Fuchs]

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
>