As I understood it:
Normally, when two (or more) goroutines call RLock, they can acquire the
read lock simultaneously without problem.
But, you cannot assume that this property always holds (see Caleb's
example).
If your algorithm relies on two goroutines holding the read lock at the
same time,
You may already know this, just in case: Forget about the mutex "locking"
anything but itself. A use of the mutex doesn't actually "protect" anything
else. Your code uses it as a traffic light -- so it knows when it's safe to
proceed without colliding with another processes's use of some data.
An
I cannot still get it!
Could you explain it to me?
Thanks ahead
在 2016年10月4日星期二 UTC+8上午5:28:11，Roberto Zanotto写道：
>
> I get it now. Thanks for your time.
>
> On Monday, October 3, 2016 at 10:55:34 PM UTC+2, Caleb Spare wrote:
>>
>> It's explained in the text afterwards:
>>
>> "This is to ensure
I get it now. Thanks for your time.
On Monday, October 3, 2016 at 10:55:34 PM UTC+2, Caleb Spare wrote:
>
> It's explained in the text afterwards:
>
> "This is to ensure that the lock eventually becomes available; a
> blocked Lock call excludes new readers from acquiring the lock."
>
> So if yo
It's explained in the text afterwards:
"This is to ensure that the lock eventually becomes available; a
blocked Lock call excludes new readers from acquiring the lock."
So if you RLock and then another goroutine tries to Lock, you might
not be able to RLock again until the first read lock is RUnl
Hi everyone.
I thought I understood clearly how an RWMutex is supposed to work, but the
documentation is giving me some troubles.
It says: "The lock can be held by an arbitrary number of readers"
which is fine by me, but then the following statement seems to contradict
it:
"If a goroutine holds
