Liam, I just wrote a little stress test program for you. Maybe it will make you less stressed. ;-) https://play.golang.org/p/5_7Geyczd1V
4 CPU 2016 MacBook Pro: *celeste:atom mtj$ go run main.go* *32 concurrent workers* *128 batches of 1048576 atomic increments, 134217728 total increments* *2.850 seconds elapsed, 47088064 atomic increments/sec* *0 collisions* 18 CPU 2019 iMacPro: *plum:atom mtj$ go run main.go* *32 concurrent workers* *128 batches of 1048576 atomic increments, 134217728 total increments* *2.730 seconds elapsed, 49167382 atomic increments/sec* *0 collisions* Exhaustive demonstration is no proof, but changing the parameters here may increase your comfort. Michael On Sat, Nov 30, 2019 at 1:02 PM Robert Engels <reng...@ix.netcom.com> wrote: > If this was broken I think a lot of things would break. > > On Nov 30, 2019, at 1:56 PM, Liam <networkimp...@gmail.com> wrote: > > > The stress test for my app fails frequently with what looks like a > collision in atomic.AddUint64() results, so I wondered whether I had > misunderstood atomic-add. > > So far I can't reproduce it with a small program, so I've probably > misunderstood my app :-) > > On Friday, November 29, 2019 at 6:41:39 PM UTC-8, Kurtis Rader wrote: >> >> On Fri, Nov 29, 2019 at 6:21 PM Liam <networ...@gmail.com> wrote: >> >>> Does atomic.AddInt32(&x, 1) always yield unique values for concurrent >>> callers? >>> >>> I'm guessing not, because (I think) I'm seeing that two callers get x+2, >>> neither gets x+1. >>> >> >> That shouldn't happen, AFAICT. Can you share the code where the incorrect >> behavior is occurring? Or, preferably, a simple reproducer program? >> >> >>> Is there a way to generate unique values with pkg atomic, or is a mutex >>> required? >>> >> >> Keep in mind that atomic.AddInt32() has the usual two's-complement >> overflow semantics. If all you want is a generation counter you really >> should be using a uint32 and atomic.AddUint32(). Also, depending on your >> preferences and performance considerations you might find it preferable to >> use a channel that holds a single int, or small number of ints, that is fed >> by a producer goroutine and consumed by any context needing a uniq ID. That >> makes it easier to abstract the generation of "unique" ints so that they >> satisfy other constraints (e.g., they must be even, odd, prime, etc.). >> >> -- >> Kurtis Rader >> Caretaker of the exceptional canines Junior and Hank >> > -- > 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/4f62dfff-6895-4aaa-9f0d-b635d5ba7ea7%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/4f62dfff-6895-4aaa-9f0d-b635d5ba7ea7%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/C7B99DEA-D183-44EF-9EDA-0B1841AB9DE5%40ix.netcom.com > <https://groups.google.com/d/msgid/golang-nuts/C7B99DEA-D183-44EF-9EDA-0B1841AB9DE5%40ix.netcom.com?utm_medium=email&utm_source=footer> > . > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@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/CALoEmQxm4LHW4n5Gs223X2UzVQ0QqBD6ZAx48_jYwve-QjXwmg%40mail.gmail.com.
