Unless you're using a 64bit atomic on a 32 bit platform, there is nothing to
worry about.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr..
The only guarantees made in regards to alignment are the ones outlined here:
https://golang.org/ref/spec#Size_and_alignment_guarantees
>From what I can tell, there is no such guarantee. But why do you care,
specifically? Using the sync/atomic package will handle this correctly in
every case. This r
Thanks for your caution. Then is there a way to know that a certain
variable is aligned properly? Will the compiler make the global variable
`var p *int` in my sample code aligned properly?
在 2017年1月9日星期一 UTC+8上午3:17:37，Dave Cheney写道：
>
> What you are talking about is called a torn write, which
The answer (like with virtually all questions like this on golang-nuts) is:
Possibly, but you can not rely on it. Assuming that it is might break your
program now or at a non-specific future date or on a non-specific current
or future processor.
If you need atomic operations, please use the sync/a
Yes, I think you are right about the case in my sample code. The code
doesn't show exactly what I'm concerned about. I just wanna know whether a
write to a global pointer in 64-bit machine an atomic operation or not.
在 2017年1月9日星期一 UTC+8上午6:22:12，Caleb Doxsey写道：
>
> Shouldn't this particular cas
Shouldn't this particular case be ok? From the memory
doc: https://golang.org/ref/mem
The go statement that starts a new goroutine happens before the goroutine's
> execution begins.
So the write has to happen before the goroutine starts. At least that's
what the example indicates:
> For ex
