On Wed, Oct 12, 2016 at 11:53 AM, Jesse McNelis <jes...@jessta.id.au> wrote:
> If you have multiple CPUs (and the Go memory model assumes that you > always can) they won't even write updated values from their cache out > to main memory until they hit a lock. > The reading CPU has read a value from main memory and put it in it's > cache, it assumes that value won't change in main memory unless it > hits a lock of it's own. > > If you don't lock then both CPUs will just sit in their own little > world updating and reading values in their own caches and are never > aware of each other. > Thanks Jesse. Good to know that. On Wed, Oct 12, 2016 at 3:26 PM, John Souvestre <j...@souvestre.com> wrote: > I see that others have already addressed the locking issued, but I noticed > something else. I don’t understand why you are using “select”. With only > one case, I think that it’s normally going to fail and exit the select > block, then loop due to the “for”. This will make it run constantly. > > > > If you get rid of the “select” then the loop will block until something > comes in from the channel. > > > > John > > John Souvestre - New Orleans LA > Please forgive me for that. I haven't been familiar with Go. -- 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.
