Using monotonic time for implementing a distributed locking system seems fraught with difficulties.
If you're using the time package to time how long operations take, just do t1 := time.Now() // time passes d := time.Since(t1) d will have the most accurate value available. On Fri, Sep 22, 2017 at 12:14 PM, Sen Han <yunthana...@gmail.com> wrote: > 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.
