Note that a lock on a sync.Mutex or sync.RWMutex is *not* held by a specific goroutine: it can be locked by one goroutine, then communicated by some other means (such as being sent on a channel) and unlocked on a *different* goroutine. (See also https://golang.org/issue/9201.)
That is: these locks *cannot* be reentrant because they do not contain goroutine-specific metadata. I read through the docs for this type again, and noticed that while the documentation for the Unlock method seems very clear on this point, the documentation for the type itself is not. (I filed https://golang.org/issue/41555, for which you are welcome to contribute <https://golang.org/doc/contribute.html> a fix!) On Monday, September 21, 2020 at 8:26:46 AM UTC-4 axel.wa...@googlemail.com wrote: > 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.wa...@googlemail.com> > wrote: > >> On Mon, Sep 21, 2020 at 2:06 PM Henrik Johansson <dahan...@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.wa...@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.wa...@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 <dahan...@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.wa...@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.wa...@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 < >>>>>>>> dahan...@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...@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/e103440c-d05c-436a-bb19-c38ffe01a8can%40googlegroups.com.
