[go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

The runtime.Gosched in the spin lock is going to be quite expensive. I found it's best to only do that every once and awhile, maybe every 100 iterations of the loop or so (you'll want to find optimal for your case). On Tuesday, October 4, 2016 at 4:09:30 AM UTC-5, sphil...@gmail.com wrote: > >

Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

You should only mutate variables inside the block that you are protecting with the locks, in this regard they are similar to the mutexes in the standard library. Be careful with the spin locks though, I would only use them where low latency is an absolute must, your go routines will sit there

Re: [go-nuts] Re: Go locking and channels much slower than Java equivalent, program spends most of time in sync.(*Mutex).Lock() and sync.(*Mutex).Unlock()

I think what Russ is saying there is don't do // routine 1 x = 5 // routine 2 atomic.LoadInt32(&x) That's mixing atomic operations on the same word. In the case of a spin lock to coordinate threads, Dmitriy's comment 15 is illustrative: 1. // goroutine 1 data = 42 atomic.Store(&ready, 1) //

[go-nuts] Re: Increasing memory usage from Gob, references never lost

Not sure if it's intended behavior, but you are using defer conn.Close() inside of an infinite for loop which means the conn never closes. On Thursday, October 13, 2016 at 4:28:57 PM UTC-5, Morgan Hein wrote: > > Hey Rob, I really appreciate you looking and responding to this. > > After your resp