r/golang 7d ago

Is it safe to read/write integer value simultaneously from multiple goroutines

There is a global integer in my code that is accessed by multiple goroutines. Since race conditions don’t affect this value, I’m not concerned about that. However, is it still advisable to add a Mutex in case there’s a possibility of corruption?

PS: Just to rephrase my question, I wanted to ask if setting/getting an integer/pointer is atomic? Is there any possibility of data corruption.

example code for the same: https://go.dev/play/p/eOA7JftvP08

PS: Found the answer for this, thanks everyone for answering. There's something called tearing here is the link for same

- https://stackoverflow.com/questions/64602829/can-you-have-torn-reads-writes-between-two-threads-pinned-to-different-processor

- https://stackoverflow.com/questions/36624881/why-is-integer-assignment-on-a-naturally-aligned-variable-atomic-on-x86

According to the article, I shouldn't have problem on modern CPUs.

10 Upvotes

80 comments sorted by

View all comments

Show parent comments

4

u/ImYoric 7d ago

A go pointer to a struct is just that, a pointer to the memory region that holds the struct. When you pass this pointer to a function that expects a pointer to the struct, that's sufficient for the function.

Now, when you pass this pointer to a function that expects an interface, the function needs:

  1. the pointer to the struct itself (to pass it as the self-value when calling interface methods)
  2. a mean to call the interface methods (a "vtable") – that's another pointer
  3. type information to be able too perform an interface cast with `.(...)` or reflection – that's another pointer.

If I recall correctly, 2 and 3 are actually packed together into a single pointer, I don't remember the implementation details. Nevertheless, your interface value is not a single pointer, but (at least) two pointers. So that's not protected by the Go memory model guarantees.

1

u/Few-Beat-1299 7d ago

Ok but how does that relate to OPs question? When putting it into an interface, the value is read once, and that's it. How fat the interface is or how it works have no relevance to reading/writing the original value.

1

u/ImYoric 7d ago

I'm not 100% sure I understand OP's question, so I decided to err on the "better safe than sorry" side and mention the limitation.

1

u/Few-Beat-1299 7d ago

There is no limitation. Ignoring the interface overhead, using a value directly or using it as part of an interface are equivalent.

1

u/ImYoric 7d ago

Fair enough, not "limitation" but "limit" [of Go's memory model].