RFR: 8145083: Use semaphore instead of mutex for synchronization of Unified Logging configuration
Marcus Larsson
marcus.larsson at oracle.com
Mon Dec 14 15:30:55 UTC 2015
Hi again,
Made some changes to the patch after feedback from Markus Grönlund. The
ConfigurationLocker and the semaphore have been moved out of the
LogConfiguration.hpp and into the .cpp instead. The lock is only used
internally by the LogConfiguration so this makes sense. It simplifies
the LogConfiguration interface and hides the details of the locking
under the hood.
New webrev:
http://cr.openjdk.java.net/~mlarsson/8145083/webrev.02/
Incremental:
http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01-02/
Thanks,
Marcus
On 2015-12-14 15:53, Marcus Larsson wrote:
> Hi,
>
> New webrev:
> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.01/
>
> Incremental:
> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00-01/
>
> Changes:
> * Introduced the ConfigurationLocker class for automatic wait/signal
> in constructor/destructor just like a MutexLocker.
> * Added an assert to verify that the "lock" is held by the current
> thread when calling configure_output.
> * Made the config-string functions in LogOutput protected and
> LogConfiguration a friend of LogOutput to prevent incorrect usage of
> these functions. These functions should typically only be used inside
> configure_output, which now ensures that the lock is held.
>
> Thanks,
> Marcus
>
>
> On 2015-12-14 11:13, Marcus Larsson wrote:
>> Hi,
>>
>> Please review the following patch to use a semaphore instead of a
>> mutex for the synchronization of log configuration. Using a mutex
>> requires some parts of the VM to be initialized, whereas the
>> semaphores can be used right from the start. This simplifies the code
>> and allows very early log configuration without special cases for
>> early configuration vs reconfiguration after VM init.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8145083/webrev.00/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8145083
>>
>> Thanks,
>> Marcus
>
More information about the serviceability-dev
mailing list