3 ms·
What "'old' value" are you talking about? This is a pointer: val := atomic.LoadUint64(&a) > Because sync.Wait() isn't used, there's no guarantee the goro
by eternalban 10y ago
What "'old' value" are you talking about?
This is a pointer:
val := atomic.LoadUint64(&a)
> Because sync.Wait() isn't used, there's no guarantee the goroutine will execute at all before program halt.
It's an infinite loop ...
> I'm not sure why atomic.Add* should get special treatment though
Because it side effects and arguably it is a form (mem) I/O in context of modern systems.
- 010a 10y ago> It's an infinite loop ... In Go, if runtime.GOMAXPROCS() returns 1 or is set to 1 (meaning, Go only has access to a single system thread), the 'for' loop canabalizes the scheduler and the goroutine is rarely or never scheduled. That fact doesn't make the OP's statement true, or have anything to do with the optimization bug, but it is worth pointing out that there are situations where Go correctly cannot guarantee that goroutine is executed.
- eternalban 10y agoYes, I am aware of that. Just addressing the OP's misread of the code. But do note that /may/ change given the GC considerations: https://github.com/golang/go/issues/10958 https://github.com/golang/go/issues/10958