> that is an atomicity issue Exactly. If you build something that does atomic reads and writes only, you are generally ignoring the larger picture of what sequence of operations needs to be atomic.
> Also the `value` entry in the struct is in small cases, prohibiting getting accessed when imported, so the side-attack to directly call `v.value` won't pass the compile phase, which is much safer than the conventional `atomic` package. Sorry, but I don't understand what you are saying at all. The operations in sync.Atomic work on individual values. They don't need a separate mutex, so you don't need to carry the value in a struct in the first place. What kind of "safety" are you referring to? If you export Load() and Save() methods then the value is available to read and write by anyone. On Monday, 23 May 2022 at 11:09:44 UTC+1 yan.z...@gmail.com wrote: > ---------- Forwarded message --------- > From: Zhaoxun Yan <yan.z...@gmail.com> > Date: Mon, May 23, 2022 at 6:05 PM > Subject: Re: [go-nuts] Improving safe global variables with generic or > inheritance > To: Brian Candler <b.ca...@pobox.com> > > *That's really essential. For example, using your library, the following > code is most definitely *not* race-free:* > > tmp := v.Load() > tmp = tmp + 1 > v.Save(tmp) > > It is race free as long as `tmp` is a local variable. > Although you may argue that another goroutine may have already altered v, > that is an atomicity issue but won't cause a `panic` or crash. My > resolution is to add a "Tick/Increase" method to substitute the above > procedure. > > Also the `value` entry in the struct is in small cases, prohibiting > getting accessed when imported, so the side-attack to directly call > `v.value` won't pass the compile phase, which is much safer than the > conventional `atomic` package. > > On Mon, May 23, 2022 at 3:11 PM Brian Candler <b.ca...@pobox.com> wrote: > >> > It's best to be intentional about it and explicitly acquire and release >> a mutex around the critical sections of your code - because ultimately, >> only your code knows which sections are critical. >> >> That's really essential. For example, using your library, the following >> code is most definitely *not* race-free: >> >> tmp := v.Load() >> tmp = tmp + 1 >> v.Save(tmp) >> >> The mutex has to protect the entire sequence, not the individual load and >> save operations. >> >> On Monday, 23 May 2022 at 07:57:02 UTC+1 axel.wa...@googlemail.com wrote: >> >>> Just to be clear, are you aware of the sync/atomic package? >>> https://pkg.go.dev/sync/atomic >>> There are also some changes in there for Go 1.18, specifically the >>> addition of some types, so that only atomic operations can be done: >>> https://pkg.go.dev/sync/atomic@master >>> I mention this because atomic.Value and atomic.Pointer[T] are >>> essentially what you are suggesting here. >>> >>> On Mon, May 23, 2022 at 8:04 AM Zhaoxun Yan <yan.z...@gmail.com> wrote: >>> >>>> However, as I want to narrow the scope of this type down to generate >>>> integer types (as in the commented code), it encountered two obstacles: >>>> >>>> 1) It is not legal to embed a generic inside a struct, nor can it make >>>> generalized computation =+1 >>>> >>>> 2) Inheritance is not available in golang, so type "Counter" cannot >>>> inherit type "Global" and get its methods automatically. I need to repeat >>>> Save and Load methods to "Counter". >>>> >>>> Am I correct? Or can you improve it? >>>> >>> >>> You are correct that there is no way in Go to write a type which gets >>> all methods from an embedded field using generics. However, that is a good >>> thing. For example, say you could write >>> >>> type Locked[T any] struct { >>> sync.Mutex >>> T >>> } >>> >>> And this would get the methods of T and the methods of sync.Mutex. Then >>> a user could do >>> >>> type Counter int64 >>> func (c *Counter) Increment() { *c += 1 } >>> >>> func main() { >>> var c Locked[Counter] >>> go c.Increment() >>> go c.Increment() >>> } >>> >>> And get a data race. That is, a method can modify a value in a way that >>> is incompatible with what your wrapper type is trying to do. >>> >>> That's really the crux of both of the obstacles you mention. You can't >>> run arbitrary computations and you can't promote methods, because *not all >>> computation and not all methods can be made concurrency safe this way*. >>> >>> It's best to be intentional about it and explicitly acquire and release >>> a mutex around the critical sections of your code - because ultimately, >>> only your code knows which sections are critical. >>> >>> >>>> >>> -- >>>> 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/baa74bff-6688-4d39-843b-c99a4fea2d1an%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/golang-nuts/baa74bff-6688-4d39-843b-c99a4fea2d1an%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> > You received this message because you are subscribed to a topic in the >> Google Groups "golang-nuts" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/golang-nuts/3javezRHm98/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> golang-nuts...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/50d6ab3d-46d0-4357-b5fa-d99b73ef2adan%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/50d6ab3d-46d0-4357-b5fa-d99b73ef2adan%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/52f27763-3c40-457a-8c6b-850e2d74108en%40googlegroups.com.
