All memory operations are unsafe for concurrent goroutines unless explicitly noted otherwise. In practice, if you have multiple goroutines accessing the same memory, you need to protect it with the primitives available to you in package sync or sync/atomic. Please review https://golang.org/ref/mem for more details.
Many Go programmers opt to sidestep these sorts of problems by using channels to orchestrate behavior and/or the flow of data between goroutines — i.e. not communicating by sharing memory, but rather sharing memory by communicating. On Mon, Sep 12, 2016 at 6:04 PM, sqweek E. <sqw...@gmail.com> wrote: > Yes, through plain assignment. What problems arise from that? > > On Monday, September 12, 2016 at 11:21:05 PM UTC+8, Peter Bourgon wrote: >> >> How are you replacing the reference to the original map? If you're >> just using plain assignment e.g. x.myMap = newMap then that's not >> safe. You could use sync/atomic.Value if you always made sure to do >> map reads via the Load method. >> >> On Mon, Sep 12, 2016 at 5:04 PM, sqweek E. <sqw...@gmail.com> wrote: >> > instead of updating the maps in place, they (a) take a >> > copy of the current map (b) update the copy and (c) replace the >> > reference to >> > the original map (held in a struct field) with the updated copy. >> > -- > 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...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
