Well, you can on modern commercial processors for local guards. It is also very easy to reason why - most lock structures use the same CAS constructs behind the scenes so you are eliminating operations in all cases.
When you say “faster” you probably mean “fairer” - as most lock free algorithms can starve /bias actors and in many cases you don’t this. For a write through cache (which this most likely is) you definitely want lock free structures (unless it is biased towards writes and in this case you probably don’t want a cache at all). This doesn’t even get into the performance possibilities of using eventually consistent/lazy methods which are even faster. All of this is predicated on proper implementation - you can review the github/robaho/go-concurrency-test to see where Go falls down a bit here. > On Jul 26, 2019, at 4:49 AM, Jesper Louis Andersen > <jesper.louis.ander...@gmail.com> wrote: > >> On Thu, Jul 25, 2019 at 1:47 PM Robert Engels <reng...@ix.netcom.com> wrote: > >> A sync.Map is lock free on read, and a single lock on writes and so will out >> perform this solution in all cases. >> > > I wouldn't just matter-of-factly place lock-free algorithms above classical > mutex locks in speed. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9143EBE6-77F8-4E98-9D4C-98C03686E16D%40ix.netcom.com.
