[Git][ghc/ghc][wip/tsan/fixes-2] 33 commits: compiler: Introduce MO_{ACQUIRE,RELEASE}_FENCE
Ben Gamari (@bgamari)
gitlab at gitlab.haskell.org
Tue Jun 20 01:48:32 UTC 2023
Ben Gamari pushed to branch wip/tsan/fixes-2 at Glasgow Haskell Compiler / GHC
Commits:
8def77f5 by Ben Gamari at 2023-06-12T09:59:21+00:00
compiler: Introduce MO_{ACQUIRE,RELEASE}_FENCE
- - - - -
fe5e6c3e by Ben Gamari at 2023-06-12T09:59:35+00:00
compiler: Drop MO_WriteBarrier
rts: Drop write_barrier
- - - - -
ab74a337 by Ben Gamari at 2023-06-12T09:59:35+00:00
rts: Drop load_store_barrier()
This is no longer used.
- - - - -
0e3e7996 by Ben Gamari at 2023-06-12T10:04:24+00:00
rts: Drop last instances of prim_{write,read}_barrier
- - - - -
95ca4cda by Ben Gamari at 2023-06-12T10:04:38+00:00
rts: Eliminate remaining uses of load_load_barrier
- - - - -
600e68d9 by Sven Tennie at 2023-06-12T10:06:49+00:00
compiler: Drop MO_ReadBarrier
- - - - -
60991d31 by Ben Gamari at 2023-06-12T10:07:03+00:00
rts: Drop load_load_barrier
This is no longer used.
- - - - -
b0705cc5 by Sven Tennie at 2023-06-12T10:07:03+00:00
Delete write_barrier function
- - - - -
3f6c3107 by Ben Gamari at 2023-06-19T21:44:51-04:00
compiler: Style fixes
- - - - -
96a91282 by Ben Gamari at 2023-06-19T21:44:51-04:00
rts/IPE: Fix unused mutex warning
- - - - -
85829dd6 by Ben Gamari at 2023-06-19T21:44:51-04:00
rts: Fix implicit cast
This ensures that Task.h can be built with a C++ compiler.
- - - - -
3a59f243 by Ben Gamari at 2023-06-19T21:44:51-04:00
rts: Fix data race in threadPaused
This only affects an assertion in the debug RTS, but it's a data race
nevertheless.
- - - - -
c89c57df by Ben Gamari at 2023-06-19T21:44:51-04:00
rts: Silence spurious data races in ticky counters
Previously we would use non-atomic accesses when bumping ticky counters,
which would result in spurious data race reports from ThreadSanitizer
when the threaded RTS was in use.
- - - - -
324351ac by Ben Gamari at 2023-06-19T21:44:51-04:00
Improve TSAN documentation
- - - - -
5ff08ecf by Ben Gamari at 2023-06-19T21:44:51-04: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.
- - - - -
f6926c69 by Ben Gamari at 2023-06-19T21:44:51-04:00
rts: Fix various data races
- - - - -
67eb640b by Ben Gamari at 2023-06-19T21:44:51-04:00
base: use atomic write when updating timer manager
- - - - -
ffdb0b13 by Ben Gamari at 2023-06-19T21:44:51-04:00
Use relaxed atomics to manipulate TSO status fields
- - - - -
af29c2bd by Ben Gamari at 2023-06-19T21:44:51-04:00
rts: Add necessary barriers when manipulating TSO owner
- - - - -
50c1fcea by Ben Gamari at 2023-06-19T21:44:51-04:00
rts: Fix synchronization on thread blocking state
- - - - -
0882023a by Ben Gamari at 2023-06-19T21:44:51-04:00
rts: Relaxed load MutVar info table
- - - - -
3c87eceb by Ben Gamari at 2023-06-19T21:44:51-04:00
hadrian: More debug information
- - - - -
a8d25dda by Ben Gamari at 2023-06-19T21:44:51-04:00
hadrian: More selective TSAN instrumentation
- - - - -
95b355d4 by Ben Gamari at 2023-06-19T21:44:52-04:00
codeGen/tsan: Rework handling of spilling
- - - - -
4ad40535 by Ben Gamari at 2023-06-19T21:45:46-04:00
codeGen: Ensure that TSAN is aware of writeArray# write barriers
- - - - -
98726ddf by Ben Gamari at 2023-06-19T21:45:48-04:00
codeGen: Ensure that array reads have necessary barriers
This was the cause of #23541.
- - - - -
e9efe54a by Ben Gamari at 2023-06-19T21:45:48-04:00
Wordsmith TSAN Note
- - - - -
befb66b5 by Ben Gamari at 2023-06-19T21:45:48-04:00
codeGen: Use relaxed accesses in ticky bumping
- - - - -
5f52ea7a by Ben Gamari at 2023-06-19T21:45:48-04:00
codeGen: Use relaxed-read in closureInfoPtr
- - - - -
0a43fe32 by Ben Gamari at 2023-06-19T21:45:48-04: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.
- - - - -
527949d9 by Ben Gamari at 2023-06-19T21:45:48-04:00
STM: Use acquire loads when possible
Full sequential consistency is not needed here.
- - - - -
73b6eef5 by Ubuntu at 2023-06-19T21:47:12-04:00
ghc-prim: Use C11 atomics
- - - - -
ed7bf9c8 by Ubuntu at 2023-06-19T21:47:12-04:00
Run script
- - - - -
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/AArch64/Instr.hs
- compiler/GHC/CmmToAsm/AArch64/Ppr.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/Prim.hs
- compiler/GHC/StgToCmm/Ticky.hs
- compiler/GHC/StgToCmm/Utils.hs
- hadrian/src/Flavour.hs
- libraries/base/GHC/Event/Thread.hs
- libraries/ghc-prim/cbits/atomic.c
- rts/Apply.cmm
- rts/CloneStack.c
- rts/Compact.cmm
- rts/Exception.cmm
- rts/Heap.c
- rts/HeapStackCheck.cmm
- rts/IPE.c
- rts/Interpreter.c
- rts/Messages.c
- rts/PrimOps.cmm
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e4eb0dd20bbab6d31a30a075694c648c9c4626e1...ed7bf9c80fe2bc3415d79c8f168a65c177345a50
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e4eb0dd20bbab6d31a30a075694c648c9c4626e1...ed7bf9c80fe2bc3415d79c8f168a65c177345a50
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/20230619/90627956/attachment-0001.html>
More information about the ghc-commits
mailing list