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님이 작성:
> 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
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
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
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
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
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
