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/CAEkBMfErLCtXNJrH5RBYUqmALGDTyQm896mFHWJzEK_WLgEVcQ%40mail.gmail.com.
