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/CAKOF694kPWH2_SA%2BE3X9bAc37LzQbCs-CtAecT8gvOmY%3DvM5rg%40mail.gmail.com.
