sync/atomic Standard PackageAtomic operations are more primitive than other synchronization techniques. They are lockless and generally implemented directly at hardware level. In fact, they are often used in implementing other synchronization techniques.
Please note, many examples below are not concurrent programs.
They are just for demonstration and explanation purposes, to show how to use the
atomic functions provided in the sync/atomic standard package.
sync/atomic standard package provides the following five atomic functions
for an integer type T, where T must be any of int32,
int64, uint32, uint64 and uintptr.
func AddT(addr *T, delta T)(new T)
func LoadT(addr *T) (val T)
func StoreT(addr *T, val T)
func SwapT(addr *T, new T) (old T)
func CompareAndSwapT(addr *T, old, new T) (swapped bool)
int32.
func AddInt32(addr *int32, delta int32)(new int32)
func LoadInt32(addr *int32) (val int32)
func StoreInt32(addr *int32, val int32)
func SwapInt32(addr *int32, new int32) (old int32)
func CompareAndSwapInt32(addr *int32,
old, new int32) (swapped bool)
The following four atomic functions are provided for (safe) pointer types. When these functions were introduced into the standard library, Go didn't support custom generics, so these functions are implemented through the unsafe pointer type
unsafe.Pointer
(the Go counterpart of C void*).
func LoadPointer(addr *unsafe.Pointer) (val unsafe.Pointer)
func StorePointer(addr *unsafe.Pointer, val unsafe.Pointer)
func SwapPointer(addr *unsafe.Pointer, new unsafe.Pointer,
) (old unsafe.Pointer)
func CompareAndSwapPointer(addr *unsafe.Pointer,
old, new unsafe.Pointer) (swapped bool)
There is not an AddPointer function for pointers,
as Go pointers don't support arithmetic operations.
sync/atomic standard package also provides a type Value.
Its corresponding pointer type *Value has two methods, Load and Store.
A Value value can be used to atomically load and store values of any type.
func (v *Value) Load() (x interface{})
func (v *Value) Store(x interface{})
The remaining of this article shows some examples on how to use the atomic operations provided in Go.
add atomic operation
on an int32 value by using the AddInt32 function.
In this example, 1000 new concurrent goroutines are created by the main goroutine.
Each of the new created goroutine increases the integer n by one.
Atomic operations guarantee that there are no data races among these goroutines.
In the end, 1000 is guaranteed to be printed.
package main
import (
"fmt"
"sync"
"sync/atomic"
)
func main() {
var n int32
var wg sync.WaitGroup
for i := 0; i < 1000; i++ {
wg.Add(1)
go func() {
atomic.AddInt32(&n, 1)
wg.Done()
}()
}
wg.Wait()
fmt.Println(atomic.LoadInt32(&n)) // 1000
}
The
StoreT and LoadT atomic functions are often used
to implement the setter and getter methods of (the corresponding pointer type of)
a type if the values of the type need to be used concurrently.
For example,
type Page struct {
views uint32
}
func (page *Page) SetViews(n uint32) {
atomic.StoreUint32(&page.views, n)
}
func (page *Page) Views() uint32 {
return atomic.LoadUint32(&page.views)
}
For a signed integer type
T (int32 or int64),
the second argument for a call to the AddT function can be a negative value,
to do an atomic decrease operation.
But how to do atomic decrease operations for values of an unsigned type T,
such as uint32, uint64 and uintptr?
There are two circumstances for the second unsigned arguments.
v of type T,
-v is legal in Go.
So we can just pass -v as the second argument of an AddT call.
c,
-c is illegal to be used as the second argument of an AddT call
(where T denotes an unsigned integer type).
We can used ^T(c-1) as the second argument instead.
This ^T(v-1) trick also works for an unsigned variable v,
but ^T(v-1) is less efficient than T(-v).
In the trick ^T(c-1), if c is a typed value
and its type is exactly T, then the form can shortened as ^(c-1).
package main
import (
"fmt"
"sync/atomic"
)
func main() {
var (
n uint64 = 97
m uint64 = 1
k int = 2
)
const (
a = 3
b uint64 = 4
c uint32 = 5
d int = 6
)
show := fmt.Println
atomic.AddUint64(&n, -m)
show(n) // 96 (97 - 1)
atomic.AddUint64(&n, -uint64(k))
show(n) // 94 (96 - 2)
atomic.AddUint64(&n, ^uint64(a - 1))
show(n) // 91 (94 - 3)
atomic.AddUint64(&n, ^(b - 1))
show(n) // 87 (91 - 4)
atomic.AddUint64(&n, ^uint64(c - 1))
show(n) // 82 (87 - 5)
atomic.AddUint64(&n, ^uint64(d - 1))
show(n) // 76 (82 - 6)
x := b; atomic.AddUint64(&n, -x)
show(n) // 72 (76 - 4)
atomic.AddUint64(&n, ^(m - 1))
show(n) // 71 (72 - 1)
atomic.AddUint64(&n, ^uint64(k - 1))
show(n) // 69 (71 - 2)
}
A SwapT function call is like a StoreT function call,
but returns the old value.
A CompareAndSwapT function call only applies the store operation
when the current value matches the passed old value.
The bool return result of the CompareAndSwapT
function call indicates whether or not the store operation is applied.
package main
import (
"fmt"
"sync/atomic"
)
func main() {
var n int64 = 123
var old = atomic.SwapInt64(&n, 789)
fmt.Println(n, old) // 789 123
swapped := atomic.CompareAndSwapInt64(&n, 123, 456)
fmt.Println(swapped) // false
fmt.Println(n) // 789
swapped = atomic.CompareAndSwapInt64(&n, 789, 456)
fmt.Println(swapped) // true
fmt.Println(n) // 456
}
Please note, up to now (Go 1.18), atomic operations for 64-bit words, a.k.a., int64 and uint64 values, require the 64-bit words must be 8-byte aligned in memory. Please read memory layout for details.
Above has mentioned that there are four functions provided in the
sync/atomic standard package to do atomic pointer operations,
with the help of unsafe pointers.
From the article type-unsafe pointers, we learn that,
in Go, values of any pointer type can be explicitly converted to unsafe.Pointer, and vice versa.
So values of *unsafe.Pointer type can also be explicitly converted to unsafe.Pointer, and vice versa.
T can be an arbitrary type.
package main
import (
"fmt"
"sync/atomic"
"unsafe"
)
type T struct {x int}
var pT *T
func main() {
var unsafePPT = (*unsafe.Pointer)(unsafe.Pointer(&pT))
var ta, tb = T{1}, T{2}
// store
atomic.StorePointer(
unsafePPT, unsafe.Pointer(&ta))
fmt.Println(pT) // &{1}
// load
pa1 := (*T)(atomic.LoadPointer(unsafePPT))
fmt.Println(pa1 == &ta) // true
// swap
pa2 := atomic.SwapPointer(
unsafePPT, unsafe.Pointer(&tb))
fmt.Println((*T)(pa2) == &ta) // true
fmt.Println(pT) // &{2}
// compare and swap
b := atomic.CompareAndSwapPointer(
unsafePPT, pa2, unsafe.Pointer(&tb))
fmt.Println(b) // false
b = atomic.CompareAndSwapPointer(
unsafePPT, unsafe.Pointer(&tb), pa2)
fmt.Println(b) // true
}
Yes, it is quite verbose to use the pointer atomic functions.
In fact, not only are the uses verbose, they are also not protected by
the Go 1 compatibility guidelines,
for these uses require to import the unsafe standard package.
Personally, I think the possibility is small that the legal pointer value
atomic operations used in the above example will become illegal later.
Even if they become illegal later, the go fix command provided in
Go Toolchain should fix them with a later alternative new legal way.
But, this is just my opinion, which is not authoritative.
If you do worry about the future legality of the pointer atomic operations used in the above example, you can use the atomic operations introduced in the next section for pointers, though the to be introduced operations are less efficient than the ones introduced in the current section.
The Value type provided in the sync/atomic standard package
can be used to atomically load and store values of any type.
Type *Value has several methods: Load, Store,
Swap and CompareAndSwap (The latter two are introduced in Go 1.17).
The input parameter types of these methods are all interface{}.
So any value may be passed to the calls to these methods.
But for an addressable Value value v,
once the v.Store() (a shorthand of (&v).Store())
call has ever been called,
then the subsequent method calls on value v must also take argument values
with the same concrete type
as the argument of the first v.Store() call,
otherwise, panics will occur.
A nil interface argument will also make the v.Store() call panic.
package main
import (
"fmt"
"sync/atomic"
)
func main() {
type T struct {a, b, c int}
var ta = T{1, 2, 3}
var v atomic.Value
v.Store(ta)
var tb = v.Load().(T)
fmt.Println(tb) // {1 2 3}
fmt.Println(ta == tb) // true
v.Store("hello") // will panic
}
package main
import (
"fmt"
"sync/atomic"
)
func main() {
type T struct {a, b, c int}
var x = T{1, 2, 3}
var y = T{4, 5, 6}
var z = T{7, 8, 9}
var v atomic.Value
v.Store(x)
fmt.Println(v) // {{1 2 3}}
old := v.Swap(y)
fmt.Println(v) // {{4 5 6}}
fmt.Println(old.(T)) // {1 2 3}
swapped := v.CompareAndSwap(x, z)
fmt.Println(swapped, v) // false {{4 5 6}}
swapped = v.CompareAndSwap(y, z)
fmt.Println(swapped, v) // true {{7 8 9}}
}
In fact, we can also use the atomic pointer functions explained in the last section to do atomic operations for values of any type, with one more level indirection. Both ways have their respective advantages and disadvantages. Which way should be used depends on the requirements in practice.
For easy using, Go atomic operations provided in the sync/atomic
standard package are designed without any relations to memory ordering.
At least the official documentation doesn't specify any memory order guarantees
made by the sync/atomic standard package.
Please read Go memory model for details.
The Go 101 project is hosted on Github. Welcome to improve Go 101 articles by submitting corrections for all kinds of mistakes, such as typos, grammar errors, wording inaccuracies, description flaws, code bugs and broken links.
If you would like to learn some Go details and facts every serveral days, please follow Go 101's official Twitter account @go100and1 or join Go 101 slack channels.
reflect standard package.sync standard package.sync/atomic standard package.