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