A lot can be argued ;)
Ambiguous docs however aren't generally good in any way. This came up as a
consequence of real code being changed by a new very skilled developer and
there was quite a bit discussion that could have been avoided with clearer
docs.
We have sorted the issue I mostly wanted to confirm my suspicion wrt nested
read locks.
On Mon, 21 Sep 2020, 13:31 Axel Wagner, <axel.wagner...@googlemail.com>
wrote:
> To elaborate a bit: You are correct in that there is a slight syntactic
> ambiguity whether "this prohibits" refers to the entire sentence ("if
> another goroutine might call Lock, then a second RLock might not be
> acquired"), or only to the second half. I would argue the rest of the
> section makes it clear that the second version is intended - "a goroutine
> can not expect a second RLock to be acquired. This prohibits…".
>
> But yes, it certainly can be argued that the ambiguity hides the
> possibility of nested RLocks when no other goroutine calls Lock. But even
> if then: Given that this would not be useful (an RLock without a concurrent
> Lock is functionally a no-op, AIUI), but *can* lead to incorrect code if
> applied improperly, that possibility doesn't seem worthwhile to advertise
> further.
>
> So even if the docs are ambiguous, that hardly seems a problem.
>
> On Mon, Sep 21, 2020 at 12:58 PM Axel Wagner <
> axel.wagner...@googlemail.com> wrote:
>
>> It only says that's excluded *if* you can have a concurrent Lock call.
>>
>> On Mon, Sep 21, 2020 at 12:48 PM Henrik Johansson <dahankz...@gmail.com>
>> wrote:
>>
>>> Yes that's the canonical deadlock but doesn't the docs say
>>>
>>> "In particular, this prohibits recursive read locking"
>>>
>>> which it doesn't unless you mix reads and writes.
>>>
>>> I get that it's not advisable but it's not prohibited either or there
>>> would be a panic or something.
>>>
>>> On Mon, 21 Sep 2020, 12:30 Axel Wagner, <axel.wagner...@googlemail.com>
>>> wrote:
>>>
>>>> (Note, FWIW, that in particular no write locks need to be *held*. It's
>>>> enough for Lock to be *called*, it doesn't have to have returned yet)
>>>>
>>>> On Mon, Sep 21, 2020 at 12:29 PM Axel Wagner <
>>>> axel.wagner...@googlemail.com> wrote:
>>>>
>>>>> I feel like the docs are pretty precise in what they say and why.
>>>>>
>>>>> a blocked Lock call excludes new readers from acquiring the lock.
>>>>>
>>>>>
>>>>> This means, the following could happen:
>>>>> Goroutine 1 calls RLock, acquires a Read-Lock
>>>>> Goroutine 2 calls Lock, blocking
>>>>> Goroutine 1 calls RLock again, blocking (as no new read locks can be
>>>>> acquired while GR 2 is blocked).
>>>>> Thus, you get a deadlock.
>>>>>
>>>>> It also has a conditional on the section
>>>>>
>>>>> If a goroutine holds a RWMutex for reading and another goroutine might
>>>>>> call Lock […]
>>>>>
>>>>>
>>>>> So if you know that no other goroutine might call Lock concurrently,
>>>>> then yes, you can call RLock twice. I can't really imagine a setting where
>>>>> you'd need an RWMutex and have that assurance and need recursive read
>>>>> locks. But there might be one.
>>>>>
>>>>> On Mon, Sep 21, 2020 at 12:16 PM Henrik Johansson <
>>>>> dahankz...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> https://golang.org/pkg/sync/#RWMutex
>>>>>>
>>>>>> Holds that this prohibits recursive read locks but why would it?
>>>>>> I understand that deadlocks can happen in case write locks are held
>>>>>> in between the read locks
>>>>>> but why can't a goroutine issue several RLock calls?
>>>>>>
>>>>>> It does actually work in the playground.
>>>>>> https://play.golang.org/p/nOehJaeikxA
>>>>>> Is this simply a recommendation or should the docs be updated to
>>>>>> clarify what this means?
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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/CAKOF696YKSGn3j%2BcyX7o0ukA7wnD2Kq19_QGefUoeMELUZGOWA%40mail.gmail.com
>>>>>> <https://groups.google.com/d/msgid/golang-nuts/CAKOF696YKSGn3j%2BcyX7o0ukA7wnD2Kq19_QGefUoeMELUZGOWA%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/CAKOF69666gwHakAoh3MsNZAFmgZFFvSTCLs9AT%2BG91ZS0H615w%40mail.gmail.com.
