aboutsummaryrefslogtreecommitdiff
path: root/misc/wasm/wasm_exec.js
diff options
context:
space:
mode:
authorMichael Pratt <mpratt@google.com>2021-10-14 18:18:49 -0400
committerDmitri Shuralyov <dmitshur@golang.org>2021-10-28 15:31:34 +0000
commit8c9c1487727a5e7938ca6ee7440334123a467b25 (patch)
treecefb66c55305d8ba63bbfa0adf40281ca9064df9 /misc/wasm/wasm_exec.js
parent1a6281d9501763b1457abe99f142f0efe435fe29 (diff)
downloadgo-8c9c1487727a5e7938ca6ee7440334123a467b25.tar.gz
go-8c9c1487727a5e7938ca6ee7440334123a467b25.zip
[release-branch.go1.16] runtime: consistently access pollDesc r/w Gs with atomics
Both netpollblock and netpollunblock read gpp using a non-atomic load. When consuming a ready event, netpollblock clears gpp using a non-atomic store, thus skipping a barrier. Thus on systems with weak memory ordering, a sequence like so this is possible: T1 T2 1. netpollblock: read gpp -> pdReady 2. netpollblock: store gpp -> 0 3. netpollunblock: read gpp -> pdReady 4. netpollunblock: return i.e., without a happens-before edge between (2) and (3), netpollunblock may read the stale value of gpp. Switch these access to use atomic loads and stores in order to create these edges. For ease of future maintainance, I've simply changed rg and wg to always be accessed atomically, though I don't believe pollOpen or pollClose require atomics today. For #48925 Fixes #49009 Change-Id: I903ea667eea320277610b4f969129935731520c3 Reviewed-on: https://go-review.googlesource.com/c/go/+/355952 Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: David Chase <drchase@google.com> (cherry picked from commit 1b072b3ed56c18619587354f499fcda5279718a2) Reviewed-on: https://go-review.googlesource.com/c/go/+/356370
Diffstat (limited to 'misc/wasm/wasm_exec.js')
0 files changed, 0 insertions, 0 deletions