Rather than hand-writing wrappers around atomic.Value, generate them
automatically from the same template. The generator is at
internal/gen-valuewrapper. The generator correctly handles generating
wrapper structs for nillable types.
Rather than hand-writing the atomic integers, generate them
automatically from the same template. The generator is at
internal/gen-atomicint.
To ensure these are never out of date, add another `make` target which
verifies that the working tree is left unchanged after regenerating
code.
In anticipation of automatically generating these definitions, pull the
definitions of the various integer types into their own files as well as
their tests.
This will make it easier to review the changes when each of these files
is generated independently and automatically.
Since String holds textual information, instead of implementing
json.Marshaler and json.Unmarshaler, we should implement
encoding.TextMarshaler and encoding.TextUnmarshaler on String.
This makes it encodable and decodable using a variety of formats
including JSON, XML, YAML, and TOML.
Support serializing and deserializing atomic objects to/from JSON using
the JSON representation of the underlying types. Without this,
marshaling returns `{}`.
Per discussion in #68, `atomic.Value` does not yet implement support
because there's an open question as to whether it should implement it
even if the underlying type doesn't support JSON marshaling/
unmarshaling.
Resolves#49
We use `golang.org/x/{tools,lint}` for dev-time tooling only. We don't
need to declare it as a library dependency. This causes issues like
https://github.com/uber-go/multierr/issues/35.
This change drops these depnedencies by renaming the tools.go so that
these are considered test dependencies only. `go mod vendor` does not
consider test dependencies.
Most methods of Bool currently rely on the last bit, but `CAS`
generates the int value to match `old` based on the user's input
and so it assumes the value is either `1` or `0`.
The only reason we relid on the last bit is that `Toggle` was
implemented using an atomic add. We can instead implement
`Toggle` using a loop around `CAS`.
Fixes#61.
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
