Sorry, ignore that. In [1], I make a copy of a locked mutex, which creates a *new *locked mutex. Basically the only non-obvious behavior here is that `&(*m) == m` by the rules of Go, the rest was explained above.
On Friday, 23 April 2021 at 9:36:26 am UTC+10 Nail Islamov wrote: > Answers above don't explain the difference in behavior: > [1] https://play.golang.org/p/lXA2F4b880W > [2] https://play.golang.org/p/doruBxrquhw > > Why did deadlock happen in [1], despite creating a variable? > If I change the order ([2]), I do avoid a deadlock (meaning that I have > two separate mutexes). > > Obviously both examples are not for production use, just trying to > understand what's happening there. > On Thursday, 22 April 2021 at 10:19:15 pm UTC+10 axel.wa...@googlemail.com > wrote: > >> I think what is going on here is that it is wrong to say that >> `(*observer)` creates a copy: >> >> https://golang.org/ref/spec#Address_operators >> >>> For an operand x of pointer type *T, the pointer indirection *x denotes >>> the variable of type T pointed to by x. >> >> >> That variable is addressable and contains a `sync.RWMutex`. It's method >> set contains `Lock`, as methods on a pointer receiver are promoted to >> value receivers <https://golang.org/ref/spec#Method_sets>. And "If x is >> addressable and &x's method set contains m, x.m() is shorthand for (&x).m()" >> <https://golang.org/ref/spec#Calls>. >> >> Thus, `(*observer).Lock()` is a shorthand for `(&(*observer)).Lock()` >> which is the same as `observer.Lock()`. >> >> If, OTOH, you do >> lock := (*observer) >> lock.Lock() >> you *would* create a copy - you'd create a new variable and assign to it >> the value in the variable pointed at by observer. >> >> Either way, I think that code should be changed. It's pretty messy and >> obviously not clear, even if it's correct. >> >> On Thu, Apr 22, 2021 at 1:49 PM Jan Mercl <0xj...@gmail.com> wrote: >> >>> On Thu, Apr 22, 2021 at 1:39 PM Mikhail Mazurskiy >>> <mikhail....@gmail.com> wrote: >>> >>> > Thanks for the response, I didn't see this section. However, I'm still >>> confused as it says the exception in 3. only applies to fields, not to >>> methods. RLock() is obviously a method, not a field. >>> >>> You're right. And because the playground link seems to work for >>> methods as well, I'm now pretty confused if there's a compiler bug or >>> specs bug or I don't understand what's going on at all. >>> >>> -- >>> 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/CAA40n-WdkuXq2u1NYfPWL2pJYq6m1pBrhEOA-qsToNUeVkFz2Q%40mail.gmail.com >>> . >>> >> -- 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/50acc2a9-64ad-45ad-84af-5ba9477aea34n%40googlegroups.com.
