Sorry I've taken so long to reply. Thanks Konstantin and Dave.
In the implementation and usage of distributed lock leases, it is
always essential to use the monotonic time API to measure the
time interval.
But in the implementation of the time package (go 1.9), there is
fallback and the go application itself couldn't know whether it is
actually using a monotonic time syscall or just the fallback
`gettimeofday` which is unsafe for the strict lease measuring:
TEXT runtime·nanotime(SB),NOSPLIT,$16
// Duplicate time.now here to avoid using up precious stack space.
// See comment above in time.now.
MOVQ *runtime·__vdso_clock_gettime_sym(SB)*, AX
CMPQ AX, $0
*JEQ fallback*
MOVL $1, DI // CLOCK_MONOTONIC
LEAQ 0(SP), SI
CALL AX
MOVQ 0(SP), AX // sec
MOVQ 8(SP), DX // nsec
// sec is in AX, nsec in DX
// return nsec in AX
IMULQ $1000000000, AX
ADDQ DX, AX
MOVQ AX, ret+0(FP)
RET
*fallback*:
LEAQ 0(SP), DI
MOVQ $0, SI
MOVQ *runtime·__vdso_gettimeofday_sym(SB)*, AX
CALL AX
MOVQ 0(SP), AX // sec
MOVL 8(SP), DX // usec
IMULQ $1000, DX
// sec is in AX, nsec in DX
// return nsec in AX
IMULQ $1000000000, AX
ADDQ DX, AX
MOVQ AX, ret+0(FP)
RET
(I think maybe it's better to add one api like 'time.IsMono' to tell the go
app
whether the monotonic clock is really & actually been used unmistakenly.)
Ps:
Although there is a in time.Now().String() for time has a monotonic
clock reading:
1. Doesn't have monotonic clock reading:
"2006-01-02 15:04:05.999999999 -0700 MST"
2. Have monotonic clock reading:
"2006-01-02 15:04:05.999999999 -0700 MST m=+2.006332106"
But it is a little strange and not straight forward to use RE to match
the
final field "m=±<value>", and most importantly, there isn't any
guarantee
about how this format will be modified in the future.
On Mon, Sep 18, 2017 at 5:47 PM, Konstantin Khomoutov <kos...@bswap.ru>
wrote:
> On Sat, Sep 16, 2017 at 04:51:00AM +0800, Sen Han wrote:
> > Thanks for your information. I want to use `ltrace` to find out if the
> > golang binary is using
> > the __vdso_clock_gettime_sym with CLOCK_MONOTONIC option for measuring
> time
> > interval.
> >
> > But it finally turns out currently the `ltrace` cannot works very well
> with
> > go built binaries on
> > vdso tracing.
> >
> > Is there some exist tools could trace the vdso call in golang? Or is
> there
> > any recommend methods
> > could achieve it on the runtime?
>
> Go is free software so instead of trying to trace the binaries its
> compiler creates, you could just grep the runtime's source code. ;-)
> Especially given the fact that since version 1.5 Go is entirely written
> in Go (modulo some assembly code).
>
> I have just grepped the checkout of 1.9 for CLOCK_MONOTONIC, and
> I think devel/golang1.9/src/runtime/sys_linux_amd64.s is what you need.
> Look for the "nanotime" function.
>
> Note that at least on i386 and amd64, Linux maps the memory ranges
> containing the data related to date/time information into the address
> space of every process, so reading these data does not involves any
> syscalls -- merely direct reads of the data located at a certain memory
> address.
>
> IIRC, on Windows, a similar mechanism is used. Don't know about other
> supported kernels.
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
