On Mon, Sep 21, 2020 at 2:06 PM Henrik Johansson <dahankz...@gmail.com>
wrote:
> 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.
>
I think it would be useful to be more explicit about the use-case then. As
I said, I can't really fathom a situation where you'd *want* to do that and
if you don't want it, I can't imagine how it would matter whether you can.
>
> 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/CAEkBMfGmdFd6U%3DmtSUE8yqZ09f5t0JNGshPpndL7J1ewREQ0AQ%40mail.gmail.com.
