Small comment updates to atomic-counters
This commit is contained in:
parent
d1ca2ce65f
commit
edab962054
@ -42,8 +42,8 @@ func main() {
|
||||
// Wait until all the goroutines are done.
|
||||
wg.Wait()
|
||||
|
||||
// Reading atomics safely while they are being updated is
|
||||
// possible using functions like `Load`, although here it's
|
||||
// safe anyway, because no goroutines are writing to 'ops'.
|
||||
// Here no goroutines are writing to 'ops', but using
|
||||
// `Load` it's safe to atomically read a value even while
|
||||
// other goroutines are (atomically) updating it.
|
||||
fmt.Println("ops:", ops.Load())
|
||||
}
|
||||
|
@ -1,2 +1,2 @@
|
||||
806f385f4485c3e9d10fe319744dd58ab77adaaf
|
||||
LfAMxMppwL-
|
||||
3435537238237eb363f652dddb405788fec98c8b
|
||||
HWE6h4-y-Fw
|
||||
|
@ -1,9 +1,10 @@
|
||||
# We expect to get exactly 50,000 operations. Had we
|
||||
# used the non-atomic `ops++` to increment the counter,
|
||||
# we'd likely get a different number, changing between
|
||||
# runs, because the goroutines would interfere with
|
||||
# each other. Moreover, we'd get data race failures
|
||||
# when running with the `-race` flag.
|
||||
# used a non-atomic integer and incremented it with
|
||||
# `ops++`, we'd likely get a different number,
|
||||
# changing between runs, because the goroutines
|
||||
# would interfere with each other. Moreover, we'd
|
||||
# get data race failures when running with the
|
||||
# `-race` flag.
|
||||
$ go run atomic-counters.go
|
||||
ops: 50000
|
||||
|
||||
|
19
public/atomic-counters
generated
19
public/atomic-counters
generated
@ -46,7 +46,7 @@ counters</em> accessed by multiple goroutines.</p>
|
||||
|
||||
</td>
|
||||
<td class="code leading">
|
||||
<a href="https://go.dev/play/p/LfAMxMppwL-"><img title="Run code" src="play.png" class="run" /></a><img title="Copy code" src="clipboard.png" class="copy" />
|
||||
<a href="https://go.dev/play/p/HWE6h4-y-Fw"><img title="Run code" src="play.png" class="run" /></a><img title="Copy code" src="clipboard.png" class="copy" />
|
||||
<pre class="chroma"><code><span class="line"><span class="cl"><span class="kn">package</span> <span class="nx">main</span></span></span></code></pre>
|
||||
</td>
|
||||
</tr>
|
||||
@ -160,9 +160,9 @@ counter exactly 1000 times.</p>
|
||||
|
||||
<tr>
|
||||
<td class="docs">
|
||||
<p>Reading atomics safely while they are being updated is
|
||||
possible using functions like <code>Load</code>, although here it’s
|
||||
safe anyway, because no goroutines are writing to ‘ops’.</p>
|
||||
<p>Here no goroutines are writing to ‘ops’, but using
|
||||
<code>Load</code> it’s safe to atomically read a value even while
|
||||
other goroutines are (atomically) updating it.</p>
|
||||
|
||||
</td>
|
||||
<td class="code">
|
||||
@ -179,11 +179,12 @@ safe anyway, because no goroutines are writing to ‘ops’.</p>
|
||||
<tr>
|
||||
<td class="docs">
|
||||
<p>We expect to get exactly 50,000 operations. Had we
|
||||
used the non-atomic <code>ops++</code> to increment the counter,
|
||||
we’d likely get a different number, changing between
|
||||
runs, because the goroutines would interfere with
|
||||
each other. Moreover, we’d get data race failures
|
||||
when running with the <code>-race</code> flag.</p>
|
||||
used a non-atomic integer and incremented it with
|
||||
<code>ops++</code>, we’d likely get a different number,
|
||||
changing between runs, because the goroutines
|
||||
would interfere with each other. Moreover, we’d
|
||||
get data race failures when running with the
|
||||
<code>-race</code> flag.</p>
|
||||
|
||||
</td>
|
||||
<td class="code leading">
|
||||
|
Loading…
x
Reference in New Issue
Block a user