when do you use sync.Mutex instead of sync.RWMutex

[김용빈]

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?

[Gregor Best]

An RWMutex will block all new readers if a writer is waiting to acquire
the lock, and that writer will only acquire the lock once all current
readers are gone.

Depending on the semantics of your application and the frequency of
writes, that might constrain the throughput through the section
protected by the lock to the rate of writes, especially if the rate of
writes and the attempts to acquire the mutex for reading are roughly in
the same order of magnitude.

> --
> 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
> <mailto:golang-nuts...@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>.

--
Gregor Best
be...@pferdewetten.de

[Axel Wagner]

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`.

--

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f597de36-b296-4f59-b756-adb1248387f5n%40googlegroups.com.

[Robert Engels]

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 <golan...@googlegroups.com> wrote:



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.

[Marcin Romaszewicz]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/2A9FF454-BD0C-4594-B3E9-FD1364077689%40ix.netcom.com.

[김용빈]

thank you all for the great answers.

now I know when I should use "RWMutex" instead of "Mutex". ;)

2020년 12월 21일 월요일 오전 1시 44분 1초 UTC+9에 mar...@gmail.com님이 작성: