Code using a simple sync.Mutex is also simpler, since you only have one way to lock and unlock and you don't have to think about lock type when writing code. In my opinion, use sync.Mutex, and if it proves to be inefficient, start investigating alternatives. In most cases, your simple code will work well enough. It's much more important to keep your critical sections small and quick than tweaking mutex behavior.
As others have said, RWMutex is great for cache-like things, but could actually work poorly in other access patterns. On Sun, Dec 20, 2020 at 4:16 AM Robert Engels <reng...@ix.netcom.com> wrote: > A cache almost always uses a RW mutex or a lock free technique like copy > on write/CAS to avoid contention. > > A simple mutex is fine for less performance critical code with guaranteed > exclusive/sequential access needs. Many transaction modes are implemented > with a simple lock/mutex. > > On Dec 20, 2020, at 6:59 AM, 'Axel Wagner' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > > > Unless I specifically know that a variable will be written rarely and read > often, I tend to use `Mutex`. I'm too worried that the preferential > treatment of write-locks in an `RWMutex` leads to surprising > contention-issues if there isn't an overwhelming relationship between their > frequencies. I also assume - given that it has the more complicated > semantics - that a `Mutex` is generally cheaper than an `RWMutex`, all > things being equal. > > So I tend to handle it the exact opposite of what you suggest - unless I > have a specific reason to use `RWMutex`, I default to `Mutex`. > > On Sun, Dec 20, 2020 at 9:44 AM 김용빈 <kyb...@gmail.com> wrote: > >> we usually both read and write for a value. not only read, nor write. >> >> with that, I feel RWMutex is always right choice. >> >> when should I use Mutex instead of RWMutex? >> >> -- >> 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/f597de36-b296-4f59-b756-adb1248387f5n%40googlegroups.com >> <https://groups.google.com/d/msgid/golang-nuts/f597de36-b296-4f59-b756-adb1248387f5n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CAEkBMfEvPFgq-cQ41Bi%3D4OtaNait-k-2iXG3yWTb8Yj%2BjHDM3Q%40mail.gmail.com > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfEvPFgq-cQ41Bi%3D4OtaNait-k-2iXG3yWTb8Yj%2BjHDM3Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- > 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/2A9FF454-BD0C-4594-B3E9-FD1364077689%40ix.netcom.com > <https://groups.google.com/d/msgid/golang-nuts/2A9FF454-BD0C-4594-B3E9-FD1364077689%40ix.netcom.com?utm_medium=email&utm_source=footer> > . > -- 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/CA%2Bv29LsF8x%2BnZ7Apnj3yyXcRwo81sYTAVU97OxzDzUtMiGHEkg%40mail.gmail.com.
