RFR(S): 8037340: Linux semaphores are associated with CLOCK_REALTIME and need relative to absolute time conversion utility

David Holmes david.holmes at oracle.com
Fri Mar 14 09:43:07 UTC 2014


Hi Markus,

This seems excessively complicated. There is no need to completely 
duplicate unpackTime the way you have (now we have three methods doing 
almost the same thing!). clock_gettime availability just shouldn't be an 
issue these days on our supported platforms, and in any case tying it to 
supports_monotonic_clock is just misleading as you may have 
clock_gettime but not a monotonic clock (unlikely but possible). If you 
are really paranoid about clock_gettime then just use gettimeofday and 
be done with it.

Further if you insisted on taking this approach change the signature to 
take secs and nsecs as it is pointless converting them to a single nsecs 
in the caller only to break them back into separate secs and nsecs 
inside the method!

Or if you really feel strongly about this form then change the signature 
to take the clock as an argument - with a default parameter providing 
CLOCK_MONOTONIC.

But I stick by what I suggested in the bug report. Just use 
clock_gettime on CLOCK_REALTIME.

David

On 14/03/2014 7:22 PM, Markus Gr?nlund wrote:
> Greetings,
>
> Kindly asking for reviews for the following changeset:
>
> 8037340: Linux semaphores are associated with CLOCK_REALTIME and need
> relative to absolute time conversion utility
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/8037340/webrev01/
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8037340
>
> Previously, unpackTime() was used to calculate the absolute time value
> for passing to sem_timedwait() for waiting on a Semaphore.
>
> UnpackTime() has been updated to be based on CLOCK_MONOTONIC which does
> not work for Semaphores, which are always associated with CLOCK_REALTIME.
>
> http://linux.die.net/man/3/sem_timedwait
>
> Thanks
>
> Markus
>


More information about the hotspot-runtime-dev mailing list