Golang timers guarantees

[te...@segment.com]

What guarantees do Golang's timers (e.g. time.After, time.Sleep) provide? If you're using lots of timers concurrently, what (if anything) could cause them to misbehave (e.g. delay)? What are they bottlenecked by?

Just curious. Thanks!

[Ian Lance Taylor]

They don't provide any guarantees other than best effort. Go is not a
hard real time programming language.

In the current implementation, if you are adding and/or removing a
very large number of timers from different goroutines running
concurrently, then I think the bottleneck would be the single lock on
runtime.timers. If you have a very large number of tickers, then I
think the bottleneck would be the runtime managing the heap of timers
that keeps the next one to fire on the top. Those are just my
guesses, though, I haven't tried to verify them.

Ian

[Tejas Manohar]

Thanks! That makes sense. For tickers, would you expect there to be loud failures (e.g. panics) or silent delays under high load? Seems like silent delays. I think this is acceptable for Go but am more wondering if I'm missing anything.

--

Best regards,

Tejas Manohar

[Ian Lance Taylor]

On Wed, Apr 5, 2017 at 10:22 AM, Tejas Manohar <te...@segment.com> wrote:
> Thanks! That makes sense. For tickers, would you expect there to be loud
> failures (e.g. panics) or silent delays under high load? Seems like silent
> delays. I think this is acceptable for Go but am more wondering if I'm
> missing anything.

Silent delays.

Ian

[Kevin Powick]

This may not be entirely applicable to your use case, but you may find the following Go proposal for Monotonic Time to be an interesting read.

https://github.com/golang/proposal/blob/master/design/12914-monotonic.md

--

Kevin Powick

[Jesper Louis Andersen]

On Wed, Apr 5, 2017 at 2:29 PM <te...@segment.com> wrote:

What guarantees do Golang's timers (e.g. time.After, time.Sleep) provide? If you're using lots of timers concurrently, what (if anything) could cause them to misbehave (e.g. delay)? What are they bottlenecked by?

Most systems with really precise timing are not concurrent systems where you can run thousands or millions of goroutines or other concurrent work. There is a trade-off to be had here and getting to sub-millisecond precision under duress is not in general achievable unless you a priori plan your schedule.

I've said it before, but most systems that claims to do lower than sub-ms latency are really systems which are high throughput(put K exclamation marks here). They work by processing extremely fast and thus they have enough time to wait around, giving the impression that they are low latency. But disturb them a little, and you will realize they tend to be extremely sensitive in the upper pecentiles because of their properties.