In migrating to Go modules, we had to decide between the import paths
github.com/uber-go/atomic and go.uber.org/atomic. We chose the latter.
As a result of this, users of the legacy import path would get an error
message similar to the following:
github.com/uber-go/atomic: github.com/uber-go/atomic@v1.5.0: parsing go.mod:
module declares its path as: go.uber.org/atomic
but was required as: github.com/uber-go/atomic
We suggested that users of the legacy import path add the following to
their go.mod.
replace github.com/uber-go/atomic => go.uber.org/atomic v1.5.0
This is inaccurate and will result in the following error message:
go.uber.org/atomic@v1.5.0 used for two different module paths
(github.com/uber-go/atomic and go.uber.org/atomic)
This was not detected before because `go mod tidy` works fine with this
`replace` directive. It fails only when it gets to `go build`.
After digging into this more, per section 4.4 of the resolution section
of [How can I resolve "parsing go.mod: unexpected module path" (..)][1],
the correct method of resolving this is to downgrade the legacy import
path to a version prior to the use of Go modules.
[1]: https://github.com/golang/go/wiki/Modules#how-can-i-resolve-parsing-gomod-unexpected-module-path-and-error-loading-module-requirements-errors-caused-by-a-mismatch-between-import-paths-vs-declared-module-identity
So the correct `replace` directive here would be,
replace github.com/uber-go/atomic => github.com/uber-go/atomic v1.4.0
This fix was verified both, locally and by @atibhav21 who first ran into
this.
This switches atomic to Go modules. This has the effect of simplifying
the Makefile and the Travis build, as well as getting rid of the overly
complicated coverage script we copied here.
Tools dependencies (currently only golint) were added to the tools.go.
As a result of this change, we no longer support the non-vanity import path
github.com/uber-go/atomic. Users must use the vanity import path, or add a
`replace` directive.
Supersedes #40
Clean up the Makefile to use ./... instead of a packages variable.
Golint checks vendor when used with "./..." so use `go list ./...`.
This lint check was previously not even running (PKGS was undefined).
Currently, we only benchmark our custom atomic types, but don't
benchmark the standard library types. Add benchmarks for ints and uints
that the standard library supports.
Atomic operations tend to be fast when there's no contention but get a
lot slower with contention, so add tests which run the same stress test
in parallel.
Currently, the stress tests start multiple goroutines, but they all have
their own local atomic, so they are not concurrently modifying the same
values. Return a function which can be run concurrently to modify the
same atomic.
This optimization causes data races since we're changing the value field
without using atomics. E.g., a caller who has multiple goroutines
calling `Set("1")` and `Set("")` will race on the access to `s.v` since
one goroutine is trying to read it while the other sets it, neither
using atomic operations.
This reverts commit 16b44f14f0.
Previously, we were not waiting for the spawned goroutines to end.
Refactor the logic to use a common runStress that runs some function
from multiple goroutines.
Unexported field name means the methods on different types look
more similar (e.g., &i.v instead of &i.int32 or &i.uint32).
For String, this is important since we don't want users to be
able to access the underlying atomic.Value
