CODEWITHSUNDEEP
go
Andonaeus
Andonaeus

Reputation: 872

Go Timer Deadlock on Stop

I am trying to reuse timers by stopping and resetting them. I am following the pattern provided by the documentation. Here is a simple example which can be run in go playground that demonstrates the issue I am experiencing.

Is there a correct way to stop and reset a timer that doesn't involve deadlock or race conditions? I am aware that using a select with default involves a race condition on channel message delivery timing and cannot be depended on.

package main

import (
    "fmt"
    "time"
    "sync"
)

func main() {
    fmt.Println("Hello, playground")

    timer := time.NewTimer(1 * time.Second)
    wg := &sync.WaitGroup{}
    wg.Add(1)

    go func(_wg *sync.WaitGroup) {
        <- timer.C
        fmt.Println("Timer done")
        _wg.Done()
    }(wg)

    wg.Wait()
    fmt.Println("Checking timer")
    if !timer.Stop() {
        <- timer.C
    }

    fmt.Println("Done")
}

Upvotes: 3

Views: 1956

Answers (2)

latitov
latitov

Reputation: 481

The question asks, in the first place, why the timer hangs. That's a good question, because even in the absence of bugs in the user program, there is... at least some weird ambiguity in how this thing, called time.Timer, works in Go. The spec says, specifically this:

Stop prevents the Timer from firing. It returns true if the call stops the timer, false if the timer has already expired or been stopped. Stop does not close the channel, to prevent a read from the channel succeeding incorrectly.

To ensure the channel is empty after a call to Stop, check the return value and drain the channel. For example, assuming the program has not received from t.C already:

if !t.Stop() {
  <-t.C
}

This cannot be done concurrent to other receives from the Timer's channel or other calls to the Timer's Stop method.

There are very short and precise words, but it may be not that easy to understand them (at least for me). I tried to use the Timer repeatedly in a piece of code, and reset it each time before the next use. Each time I do so, I may want to Stop() it - just for sure. The spec above implies how you should do that, and provides an example - and it may not work! It depends, it depends where you try to apply the Stop idiom. In case you do it after you already in a select-case on this very timer, then it will hang the program.

Specifically, I do not have any concurrent receivers, only a single goroutine. So let's make a simple test program, and try to experiment with it (https://play.golang.org/p/d7BlNReE9Jz):

package main

import (
    "fmt"
    "time"
)

func main() {
    i := 0
    d2s := time.Second * 1
    
    i++; fmt.Println(i)
    
    t := time.NewTimer(d2s)
    <-t.C
    i++; fmt.Println(i)

    t.Reset(d2s)
    <-t.C
    i++; fmt.Println(i)

//  if !t.Stop() { <-t.C }
//  if !t.Stop() { select { case <-t.C: default: } }
    t.Reset(d2s)
    <-t.C
    i++; fmt.Println(i)

}

This code WORKS. It prints 1,2,3,4, delayed by 1 sec, and that's what it is expected to print. So far so good.

Now, try to un-comment the first commented line. Now the thing: according to spec, it is 100% right (is it?), and must work, but it does not, and hangs. Why? Because, according to spec, it must hang! I already read the channel, and the timer is stopped, so the if fires, and the channel drain op hangs.

Is this a bug? No. Is the spec wrong? No, it's correct. But, it's contrary to what a typical timer user would want. (Maybe a subject for proposal to Go?). All we need, is something like:

t.SafeStopDrain()

Which would do this right, and never hang. But, sadly, it is non-existent.

Here's the life-hack, the workaround, to make this work, is the second commented line. Un-comment it, and that will both work, and do what you wanted - make sure the timer is stopped, channel drained, and the whole thing is fresh anew for re-use.

Upvotes: 3

colm.anseo
colm.anseo

Reputation: 22097

According to the timer.Stop docs, there is a caveat for draining the channel:

assuming the program has not received from t.C already ...

This cannot be done concurrent to other receives from the Timer's channel.

Since the channel has already been drained - and will never fire again, the second <-timer.C will block forever.

Upvotes: 3

Related Questions