On Monday, April 15, 2019 at 8:16:53 AM UTC-5, michae...@gmail.com wrote:
> FWIW, here's the pattern I've settled on for my actual application.
>
> https://play.golang.org/p/OBVsp-Rjknf
>
>
> It uses sync.Mutex only and includes the mutex as a member of the
> guardedState struct. The deciding
FWIW, here's the pattern I've settled on for my actual application.
https://play.golang.org/p/OBVsp-Rjknf
It uses sync.Mutex only and includes the mutex as a member of the
guardedState struct. The deciding factor was that my industrial control
application has a very large state struct with ov
I believe you only need one or the other; I assumed a use case like this:
https://play.golang.org/p/nSgyiXU87XN
On Sun, Apr 14, 2019 at 1:33 PM wrote:
> I found a good discussion in the FAQ that explains the problem clearly.
> https://golang.org/doc/faq#methods_on_values_or_pointers
>
> I thin
On Sunday, April 14, 2019 at 8:16:11 PM UTC+2, Matt Harden wrote:
>
> No, you don't need sync/atomic. The mutex is sufficient. By the way, you
> should put the mutex inside of guardedState, next to the data being
> guarded. Had you done that originally, Go Vet would have complained about
> you p
I found a good discussion in the FAQ that explains the problem clearly.
https://golang.org/doc/faq#methods_on_values_or_pointers
I think the mutex is needed on the update function with or without the use
of sync/atomic. The atomic guards the Load and the Store but the func is
operating on the
Good to know about not needing sync/atomic. I used a pointer to an
externally defined mutex because an answer I found on StackOverflow
recommended doing that. However, on looking at my application more closely
I think you're right about putting it inside the struct.
On Sunday, April 14, 2019
I don't know if it's documented or not. In the language reference you can
see the rules for method calls:
https://golang.org/ref/spec#Calls
https://golang.org/ref/spec#Method_sets
A hint might have been that object should have mutated, but it didn't.
It's in a class of errors that becomes recogn
No, you don't need sync/atomic. The mutex is sufficient. By the way, you
should put the mutex inside of guardedState, next to the data being
guarded. Had you done that originally, Go Vet would have complained about
you passing guardedState by value (mutexes should never by copied).
https://play.go
Thanks, Skip. That fixes it. Is the need for a pointer receiver documented
somewhere? It's not something that even crossed my mind given that the
neither the compiler nor golint complained. I suppose it makes sense if I
think of func (x) foo(y) {} as being an alternate way of writing func
foo(
The receiver for load and update should be the original object not a copy.
https://play.golang.org/p/XCZC0OVhGMa
On Sun, Apr 14, 2019, 7:56 AM wrote:
>
> https://play.golang.org/p/6aQYNjojyBD
>
> I'm clearly missing something about the way sync.Mutex and atomic.Value
> work in Go.
>
> I'm attem
https://play.golang.org/p/6aQYNjojyBD
I'm clearly missing something about the way sync.Mutex and atomic.Value
work in Go.
I'm attempting to write a pair of concurrency safe methods, load() and
update(), for accessing a struct. The struct is stored as an atomic.Value
and accessed with atomic.
11 matches
Mail list logo
