true. not roust that way. also, it uses "Go array bounds checking" as the
implicit test for crazy out of range values. just a 5 min stream of
consciousness hack to defend the honor of the Go atomic primitives. ;-) It
was typed one handed while the the other propped up my macbook here in bed.
easily
Sorry, I hadn’t looked at the code, but after reviewing doesn’t your code not
detect the case where a value was skipped ? (... not that it could happen - but
for completeness of the robust test)
> On Dec 1, 2019, at 10:44 PM, Michael Jones wrote:
>
> not necessary as the testing and updating i
"Oh you've allocated a bit array for every value in the test range, then
checked for gaps in it?"
Yes. What I should have said. (Though the test looks not for gaps but for
two pigeons in one hole, but the same idea.)
On Sun, Dec 1, 2019 at 8:44 PM Michael Jones
wrote:
> not necessary as the tes
not necessary as the testing and updating is only done in one place by one
the main goroutine.
On Sun, Dec 1, 2019 at 7:46 PM Robert Engels wrote:
> The updating of the bit array if shared needs to atomic as well, probably
> with a read and cas.
>
> On Dec 1, 2019, at 9:19 PM, Liam wrote:
>
>
The updating of the bit array if shared needs to atomic as well, probably with
a read and cas.
> On Dec 1, 2019, at 9:19 PM, Liam wrote:
>
>
> Oh you've allocated a bit array for every value in the test range, then
> checked for gaps in it?
>
>> On Sunday, December 1, 2019 at 2:21:55 PM U
Oh you've allocated a bit array for every value in the test range, then
checked for gaps in it?
On Sunday, December 1, 2019 at 2:21:55 PM UTC-8, Michael Jones wrote:
>
> Oh! That's just a bit per integer in the test range 0..total-1. Since Go
> (and everything else) lacks a bit type, I just type
agree, makes sense. also if you trust the compiler, change to use the mod
function, etc.
On Sun, Dec 1, 2019 at 2:31 PM robert engels wrote:
> I’d prefer v / 8 over v >> 3 - provides more context in my opinion. The
> compiler will change to right shift if more efficient anyway.
>
> On Dec 1, 201
I’d prefer v / 8 over v >> 3 - provides more context in my opinion. The
compiler will change to right shift if more efficient anyway.
> On Dec 1, 2019, at 4:21 PM, Michael Jones wrote:
>
> Oh! That's just a bit per integer in the test range 0..total-1. Since Go (and
> everything else) lacks a
Oh! That's just a bit per integer in the test range 0..total-1. Since Go
(and everything else) lacks a bit type, I just type such code
automatically. Bytes hold 8 bits. Array size must be rounded up, so
a := make([]byte, (total+8-1)/8)
array index for test integer n is n/8, so "n>>3"
bit index f
I wrote a less-sophisticated version of your test, then realized I'd
misspent my time; all I needed was to change the atomic.Add*() to a
mutex-protected counter, and see whether my app still failed; it did.
But since you took the trouble, I read your code, and would like to
understand your coll
As a follow-up, some more timing:
*47088064 atomic increments/sec (my original email above for heavy
synchronization conflict incrementing)*
142049067 atomic increments/sec when each goroutine has its own atomic
update target. (Not testing global synchronization/mutex, just the
overhead of conges
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.85
If this was broken I think a lot of things would break.
> On Nov 30, 2019, at 1:56 PM, Liam 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
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
On Fri, Nov 29, 2019 at 6:21 PM Liam 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 incorr
On Fri, Nov 29, 2019 at 7:21 PM Liam 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 should not happen, afaik. Do you have code you can share?
>
> Is t
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.
Is there a way to generate unique values with pkg atomic, or is a mutex
required?
--
You received this message because you
17 matches
Mail list logo
