Is assigning a pointer atomic in Go?

Is assigning a pointer atomic in Go?

Do I need to assign a pointer in a lock? Suppose I just want to assign the pointer to nil, and would like other threads to be able to see it. I know in Java we can use volatile for this, but there is no volatile in Go.

The only things which are guaranteed to be atomic in go are the operations in sync.atomic.

So if you want to be certain you'll either need to take a lock, eg sync.Mutex or use one of the atomic primitives. I don't recommend using the atomic primitives though as you'll have to use them everywhere you use the pointer and they are difficult to get right.

Using the mutex is OK go style - you could define a function to return the current pointer with locking very easily, eg something like

import "sync"

var secretPointer *int
var pointerLock sync.Mutex

func CurrentPointer() *int {
	pointerLock.Lock()
	defer pointerLock.Unlock()
	return secretPointer
}

func SetPointer(p *int) {
	pointerLock.Lock()
	secretPointer = p
	pointerLock.Unlock()
}

These functions return a copy of the pointer to their clients which will stay constant even if the master pointer is changed. This may or may not be acceptable depending on how time critical your requirement is. It should be enough to avoid any undefined behaviour - the garbage collector will ensure that the pointers remain valid at all times even if the memory pointed to is no longer used by your program.

An alternative approach would be to only do the pointer access from one go routine and use channels to command that go routine into doing things. That would be considered more idiomatic go, but may not suit your application exactly.

Update

Here is an example showing how to use atomic.SetPointer. It is rather ugly due to the use of unsafe.Pointer. However unsafe.Pointer casts compile to nothing so the runtime cost is small.

import (
	"fmt"
	"sync/atomic"
	"unsafe"
)

type Struct struct {
	p unsafe.Pointer // some pointer
}

func main() {
	data := 1

	info := Struct{p: unsafe.Pointer(&data)}

	fmt.Printf("info is %d\n", *(*int)(info.p))

	otherData := 2

	atomic.StorePointer(&info.p, unsafe.Pointer(&otherData))

	fmt.Printf("info is %d\n", *(*int)(info.p))

}

Since the spec doesn't specify you should assume it is not. Even if it is currently atomic it's possible that it could change without ever violating the spec.

In addition to Nick's answer, since Go 1.4 there is atomic.Value type. Its Store(interface) and Load() interface methods take care of the unsafe.Pointer conversion.

Simple example:

package main

import (
	"sync/atomic"
)

type stats struct{}

type myType struct {
	stats atomic.Value
}

func main() {
	var t myType
	
	s := new(stats)
	
	t.stats.Store(s)
	
	s = t.stats.Load().(*stats)
}

Or a more extended example from the documentation on the Go playground.

Since Go 1.19 atomic.Pointer is added into atomic

> The sync/atomic package defines new atomic types Bool, Int32, Int64, Uint32, Uint64, Uintptr, and Pointer. These types hide the underlying values so that all accesses are forced to use the atomic APIs. Pointer also avoids the need to convert to unsafe.Pointer at call sites. Int64 and Uint64 are automatically aligned to 64-bit boundaries in structs and allocated data, even on 32-bit systems.

Sample

type ServerConn struct {
	Connection net.Conn
	ID string
}

func ShowConnection(p *atomic.Pointer[ServerConn]) {
	for {
		time.Sleep(10 * time.Second)
		fmt.Println(p, p.Load())
	}
}
func main() {
	c := make(chan bool)
	p := atomic.Pointer[ServerConn]{}
	s := ServerConn{ID: "first_conn"}
	p.Store(&s)
	go ShowConnection(&p)
	go func() {
		for {
			time.Sleep(13 * time.Second)
			newConn := ServerConn{ID: "new_conn"}
			p.Swap(&newConn)
		}
	}()
	<-c
}

Please note that atomicity has nothing to do with "I just want to assign the pointer to nil, and would like other threads to be able to see it". The latter property is called visibility.

The answer to the former, as of right now is yes, assigning (loading/storing) a pointer is atomic in Golang, this lies in the updated Go memory model

> Otherwise, a read r of a memory location x that is not larger than a machine word must observe some write w such that r does not happen before w and there is no write w' such that w happens before w' and w' happens before r. That is, each read must observe a value written by a preceding or concurrent write.

Regarding visibility, the question does not have enough information to be answered concretely. If you merely want to know if you can dereference the pointer safely, then a plain load/store would be enough. However, the most likely cases are that you want to communicate some information based on the nullness of the pointer. This requires you using sync/atomic, which provides synchronisation capabilities.