On Fri, Apr 23, 2021 at 1:36 AM Nail Islamov <nile...@gmail.com> 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). > In [1], you copy a locked mutex and try to lock that. In [2], you copy an unlocked Mutex (really, the zero value of a Mutex) and try to lock that (which works). Note that in case [1] the behavior actually is undefined: https://golang.org/pkg/sync/#Mutex > A Mutex must not be copied after first use. In case [2] you copy it before first use, which is fine (as I said, you are copying the zero value of a Mutex). > > 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 > <https://groups.google.com/d/msgid/golang-nuts/14845b83-4292-4b39-8098-ef914e2b4254n%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/CAEkBMfG9k1ZJ4ioxnSr6X3PFM7syL1NfddUKA-Ta-u%3DEArhXGA%40mail.gmail.com.
