On Wed, Sep 23, 2020 at 11:25 AM Henrik Johansson <dahankz...@gmail.com> wrote:
> This is funny, why isn't there a panic in this case? It clearly "works" as > in it doesn't deadlock or panics assuming a write lock isn't somehow mixed > incorrectly. > Why would there be a panic? The behavior is well-defined and documented. (Admittedly the documentation is a bit awkward, but documentation is hard to get exactly right.) On Tue, Sep 22, 2020 at 3:56 PM 'Bryan C. Mills' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >> 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 >> <https://groups.google.com/d/msgid/golang-nuts/e103440c-d05c-436a-bb19-c38ffe01a8can%40googlegroups.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/CAKWVi_S8s%3DaJxP0b7JbHusXCTvTMKSoh2PKAHcqw_%2B%2B26fmiLw%40mail.gmail.com.
