Data race if used as a drop in replacement for `sync.Once`.

Nobody has claimed this yet.

If you use `Do` to write something and then _after_ that read that something (the exact use case in your example). Then there is data race if anyone else does a `Reset` and then does the `Do` again (e.g. while handling an http request a reset request and a second request come in before you finish).

IMO, [`atomic.Value`](https://golang.org/pkg/sync/atomic/#Value) is a better tool for the example you gave.

To demonstrate, add `race_test.go` as below and then do `go test -v -race -cpu=8`:

```
package resync

import (
"runtime"
"sync"
"testing"
)

var global int
var o Once

func something() {
o.Do(func() {
global++
})
x := global
for i := 0; i < 1e5; i++ {
x += global
}
}

func TestRace(t *testing.T) {
n := runtime.GOMAXPROCS(-1)
if n < 2 {
t.Skip("Run test with -race and -cpu")
}
n *= 2
var wg sync.WaitGroup
wg.Add(n)
for j := 0; j < n; j++ {
go func() {
something()
o.Reset()
wg.Done()
}()
}
wg.Wait()
}
```

Add the reported race_test.go to the resync package and run `go test -v -race -cpu=8` to reproduce the data race. Read the `Once` implementation and its `Do` and `Reset` entry points, then determine the intended safe behavior for reads after a reset; done means the race scenario and resolution are covered by tests.

Written by the indexing model from the issue text.