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.

Reply via email to