Small comment updates to atomic-counters

This commit is contained in:
Eli Bendersky 2023-10-02 05:48:21 -07:00
parent d1ca2ce65f
commit edab962054
4 changed files with 21 additions and 19 deletions

View File

@ -42,8 +42,8 @@ func main() {
// Wait until all the goroutines are done. // Wait until all the goroutines are done.
wg.Wait() wg.Wait()
// Reading atomics safely while they are being updated is // Here no goroutines are writing to 'ops', but using
// possible using functions like `Load`, although here it's // `Load` it's safe to atomically read a value even while
// safe anyway, because no goroutines are writing to 'ops'. // other goroutines are (atomically) updating it.
fmt.Println("ops:", ops.Load()) fmt.Println("ops:", ops.Load())
} }

View File

@ -1,2 +1,2 @@
806f385f4485c3e9d10fe319744dd58ab77adaaf 3435537238237eb363f652dddb405788fec98c8b
LfAMxMppwL- HWE6h4-y-Fw

View File

@ -1,9 +1,10 @@
# We expect to get exactly 50,000 operations. Had we # We expect to get exactly 50,000 operations. Had we
# used the non-atomic `ops++` to increment the counter, # used a non-atomic integer and incremented it with
# we'd likely get a different number, changing between # `ops++`, we'd likely get a different number,
# runs, because the goroutines would interfere with # changing between runs, because the goroutines
# each other. Moreover, we'd get data race failures # would interfere with each other. Moreover, we'd
# when running with the `-race` flag. # get data race failures when running with the
# `-race` flag.
$ go run atomic-counters.go $ go run atomic-counters.go
ops: 50000 ops: 50000

19
public/atomic-counters generated
View File

@ -46,7 +46,7 @@ counters</em> accessed by multiple goroutines.</p>
</td> </td>
<td class="code leading"> <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> <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> </td>
</tr> </tr>
@ -160,9 +160,9 @@ counter exactly 1000 times.</p>
<tr> <tr>
<td class="docs"> <td class="docs">
<p>Reading atomics safely while they are being updated is <p>Here no goroutines are writing to &lsquo;ops&rsquo;, but using
possible using functions like <code>Load</code>, although here it&rsquo;s <code>Load</code> it&rsquo;s safe to atomically read a value even while
safe anyway, because no goroutines are writing to &lsquo;ops&rsquo;.</p> other goroutines are (atomically) updating it.</p>
</td> </td>
<td class="code"> <td class="code">
@ -179,11 +179,12 @@ safe anyway, because no goroutines are writing to &lsquo;ops&rsquo;.</p>
<tr> <tr>
<td class="docs"> <td class="docs">
<p>We expect to get exactly 50,000 operations. Had we <p>We expect to get exactly 50,000 operations. Had we
used the non-atomic <code>ops++</code> to increment the counter, used a non-atomic integer and incremented it with
we&rsquo;d likely get a different number, changing between <code>ops++</code>, we&rsquo;d likely get a different number,
runs, because the goroutines would interfere with changing between runs, because the goroutines
each other. Moreover, we&rsquo;d get data race failures would interfere with each other. Moreover, we&rsquo;d
when running with the <code>-race</code> flag.</p> get data race failures when running with the
<code>-race</code> flag.</p>
</td> </td>
<td class="code leading"> <td class="code leading">