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/CAEkBMfFFFYpqCPSkEa%2B5iUy-CGeA4HoGkSaHGzgL60fO8sKE%2BQ%40mail.gmail.com.
