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/14845b83-4292-4b39-8098-ef914e2b4254n%40googlegroups.com.
