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 spinning in the infinite loop until some other routine unlocks which is going to cost CPU. On Tuesday, October 11, 2016 at 11:20:15 PM UTC-5, Henrik Johansson wrote: > > But do these types of spin locks provide the same memory effects as > standard locks? I get that only one goroutine at a time can run the given > block but assigning to shared vars inside the block will still need to use > the methods from sync/atomic right? > > On Tue, Oct 11, 2016, 22:47 <hiatt....@gmail.com <javascript:>> wrote: > >> 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: >>> >>> Try spinlocks instead of mutexes: >>> https://github.com/pi/goal/blob/master/gut/spinlock.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...@googlegroups.com <javascript:>. >> 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.
