How did you manage visibility between routines?

[rFronteddu]

I was looking at your car example and I noticed that you do:

	for {
		<-time.After(time.Second)
		c.Miles += float64(c.Speed)
	}

And that Miles is consistently updated when I do a restconf get. Since I don't see any locking and I think the operations over Miles are done in separate routines, I was wondering if this is a side effect of my architecture and if the example shouldn't instead be done using locks to guarantee visibility between updates.

[dhubler]

Can you describe your issue in terms of what you expected, what you see instead with a working example that demonstrates the issue? re:locking scalar values like float64 are non-volatile. Absolute worst case you get a value that is micro-seconds older. If you really suspect

…

On Mon, Jul 24, 2023 at 4:53 PM Roberto Fronteddu ***@***.***> wrote: I was looking at your car example and I noticed that you do: for { <-time.After(time.Second) c.Miles += float64(c.Speed) } And that Miles is consistently updated when I do a restconf get. Since I don't see any locking and I think the operations over Miles are done in separate routines, I was wondering if this is a side effect of my architecture and if the example shouldn't instead be done using locks to guarantee visibility between updates. — Reply to this email directly, view it on GitHub <#42>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACA7SON2ZBFAJZL7U5CL3XR3ODZANCNFSM6AAAAAA2WDY2DY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rFronteddu]

Forgive me for the late reply.

I am not sure I follow. It is my understanding that unless you manually lock or use a channel, there is no guarantee that an update from a go routine will be visible from another. In this case, it may work due to hardware architecture but I don't think we should rely on that. Am I missing something?