Forgot the list, sorry. ---------- Forwarded message --------- From: Henrik Johansson <dahankz...@gmail.com> Date: ons 12 okt. 2016 kl 08:32 Subject: 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() To: Dustin Hiatt <hiatt.dus...@gmail.com>
Thats a good read but consider the following: https://play.golang.org/p/j2XVkmcfRl Is this adequately safe in light of the discussion in that thread? Specially the last comment by +rsc seems interesting. ons 12 okt. 2016 kl 07:39 skrev Dustin Hiatt <hiatt.dus...@gmail.com>: I'm not entirely sure, but my gut tells me there's probably strict ordering across threads there. More info can be found here: https://github.com/golang/go/issues/5045 On Wed, Oct 12, 2016 at 12:02 AM, Henrik Johansson <dahankz...@gmail.com> wrote: Yes I get that but it seems as there other constraints at play here wrt the memory model. In essence the spin locks (unless described outside their code somewhere) state that one measly atomic load has the same memory effects as a sync/lock which seems like it might work on some platforms (maybe) but surely not for all? Don't I at least have to load the shared vars using atomic load (atomic.Value for example) or something similar? My point is that the protected section isn't guaranteed the same memory rules as when protected by a standard lock. ons 12 okt. 2016 kl 06:36 skrev <hiatt.dus...@gmail.com>: 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> 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. 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. -- 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.
