[Git][ghc/ghc][wip/tsan/fix-races] 19 commits: Fix thunk update ordering
Ben Gamari (@bgamari)
gitlab at gitlab.haskell.org
Mon Dec 18 21:48:26 UTC 2023
Ben Gamari pushed to branch wip/tsan/fix-races at Glasgow Haskell Compiler / GHC
Commits:
5e2de30e by Ben Gamari at 2023-12-18T16:46:32-05:00
Fix thunk update ordering
Previously we attempted to ensure soundness of concurrent thunk update
by synchronizing on the access of the thunk's info table pointer field.
This was believed to be sufficient since the indirectee (which may
expose a closure allocated by another core) would not be examined
until the info table pointer update is complete.
However, it turns out that this can result in data races in the presence
of multiple threads racing a update a single thunk. For instance,
consider this interleaving under the old scheme:
Thread A Thread B
--------- ---------
t=0 Enter t
1 Push update frame
2 Begin evaluation
4 Pause thread
5 t.indirectee=tso
6 Release t.info=BLACKHOLE
7 ... (e.g. GC)
8 Resume thread
9 Finish evaluation
10 Relaxed t.indirectee=x
11 Load t.info
12 Acquire fence
13 Inspect t.indirectee
14 Release t.info=BLACKHOLE
Here Thread A enters thunk `t` but is soon paused, resulting in `t`
being lazily blackholed at t=6. Then, at t=10 Thread A finishes
evaluation and updates `t.indirectee` with a relaxed store.
Meanwhile, Thread B enters the blackhole. Under the old scheme this
would introduce an acquire-fence but this would only synchronize with
Thread A at t=6. Consequently, the result of the evaluation, `x`, is not
visible to Thread B, introducing a data race.
We fix this by treating the `indirectee` field as we do all other
mutable fields. This means we must always access this field with
acquire-loads and release-stores.
See #23185.
- - - - -
fee12884 by Ben Gamari at 2023-12-18T16:47:48-05:00
rts: Fix data race in threadPaused
This only affects an assertion in the debug RTS and only needs relaxed
ordering.
- - - - -
77a47ff8 by Ben Gamari at 2023-12-18T16:47:48-05:00
cmm: Introduce MO_RelaxedRead
In hand-written Cmm it can sometimes be necessary to atomically load
from memory deep within an expression (e.g. see the `CHECK_GC` macro).
This MachOp provides a convenient way to do so without breaking the
expression into multiple statements.
- - - - -
90d7db1c by Ben Gamari at 2023-12-18T16:47:48-05:00
codeGen: Use relaxed accesses in ticky bumping
- - - - -
a059338c by Ben Gamari at 2023-12-18T16:47:48-05:00
rts: Fix data race in Interpreter's preemption check
- - - - -
fc7e6b8a by Ben Gamari at 2023-12-18T16:47:48-05:00
rts: Fix data race in threadStatus#
- - - - -
83a287a2 by Ben Gamari at 2023-12-18T16:47:49-05:00
base: use atomic write when updating timer manager
- - - - -
6ab09c9b by Ben Gamari at 2023-12-18T16:47:49-05:00
Use relaxed atomics to manipulate TSO status fields
- - - - -
66f14cd5 by Ben Gamari at 2023-12-18T16:47:49-05:00
rts: Add necessary barriers when manipulating TSO owner
- - - - -
2ee967e0 by Ben Gamari at 2023-12-18T16:47:49-05:00
rts: Use `switch` to branch on why_blocked
This is a semantics-preserving refactoring.
- - - - -
d3bd4c6a by Ben Gamari at 2023-12-18T16:47:49-05:00
rts: Fix synchronization on thread blocking state
We now use a release barrier whenever we update a thread's blocking
state. This required widening StgTSO.why_blocked as AArch64 does not
support atomic writes on 16-bit values.
- - - - -
c8a7f1a3 by Ben Gamari at 2023-12-18T16:47:49-05:00
rts: Use relaxed ordering on dirty/clean info tables updates
When changing the dirty/clean state of a mutable object we needn't have
any particular ordering.
- - - - -
41a2c5a4 by Ben Gamari at 2023-12-18T16:47:49-05:00
codeGen: Use relaxed-read in closureInfoPtr
- - - - -
58ea59c3 by Ben Gamari at 2023-12-18T16:47:49-05:00
STM: Use acquire loads when possible
Full sequential consistency is not needed here.
- - - - -
59c09ad8 by Ben Gamari at 2023-12-18T16:47:49-05:00
rts/Messages: Fix data race
- - - - -
7c72c48f by Ben Gamari at 2023-12-18T16:47:49-05:00
rts/Prof: Fix data race
- - - - -
1d84289e by Ben Gamari at 2023-12-18T16:47:49-05:00
rts: Use fence rather than redundant load
Previously we would use an atomic load to ensure acquire ordering.
However, we now have `ACQUIRE_FENCE_ON`, which allows us to express this
more directly.
- - - - -
cab220b5 by Ben Gamari at 2023-12-18T16:47:49-05:00
rts: Fix data races in profiling timer
- - - - -
b7ce97d0 by Ben Gamari at 2023-12-18T16:47:49-05:00
Add Note [C11 memory model]
- - - - -
30 changed files:
- compiler/GHC/Cmm/Expr.hs
- compiler/GHC/Cmm/Info.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Parser.y
- compiler/GHC/Cmm/ThreadSanitizer.hs
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/PPC/CodeGen.hs
- compiler/GHC/CmmToAsm/Wasm/FromCmm.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/CmmToC.hs
- compiler/GHC/CmmToLlvm/CodeGen.hs
- compiler/GHC/StgToCmm/Bind.hs
- compiler/GHC/StgToCmm/Ticky.hs
- compiler/GHC/StgToCmm/Utils.hs
- libraries/base/src/GHC/Event/Thread.hs
- rts/Apply.cmm
- rts/Compact.cmm
- rts/Exception.cmm
- rts/Heap.c
- rts/HeapStackCheck.cmm
- rts/Interpreter.c
- rts/Messages.c
- rts/PrimOps.cmm
- rts/Proftimer.c
- rts/RaiseAsync.c
- rts/STM.c
- rts/Schedule.c
- rts/StableName.c
- rts/StgMiscClosures.cmm
- rts/StgStartup.cmm
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d6e45c01d61bf4cb300f4192794b059e4a2697b6...b7ce97d0412a08f3b31f24a7595c54a052ef1231
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d6e45c01d61bf4cb300f4192794b059e4a2697b6...b7ce97d0412a08f3b31f24a7595c54a052ef1231
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20231218/55cf4c5f/attachment-0001.html>
More information about the ghc-commits
mailing list