FTR, I still don't think the docs *are* ambiguous. The authoritative part is
If a goroutine holds a RWMutex for reading and another goroutine might call
> Lock, no goroutine should expect to be able to acquire a read lock until
> the initial read lock is released.
The rest is just additional explanation. This sentence alone is already
sufficient to define the behavior.
On Mon, Sep 21, 2020 at 2:14 PM Axel Wagner <axel.wagner...@googlemail.com>
wrote:
> 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/CAEkBMfFRk1%3DVMMmq-MJVAz1zio4rnSMOo9TYKtkn-VHF4hH-Pw%40mail.gmail.com.
