[Git][ghc/ghc][wip/tsan/fixes-2] 22 commits: rts: Fix synchronization on thread blocking state

Ben Gamari (@bgamari) gitlab at gitlab.haskell.org
Fri Jun 23 20:22:40 UTC 2023 


Ben Gamari pushed to branch wip/tsan/fixes-2 at Glasgow Haskell Compiler / GHC


Commits:
f4499a11 by Ben Gamari at 2023-06-23T16:22:32-04:00
rts: Fix synchronization on thread blocking state

- - - - -
108b9164 by Ben Gamari at 2023-06-23T16:22:32-04:00
rts: Relaxed load MutVar info table

- - - - -
1e0e47ca by Ben Gamari at 2023-06-23T16:22:32-04:00
hadrian: More debug information

- - - - -
4bdd4370 by Ben Gamari at 2023-06-23T16:22:32-04:00
hadrian: More selective TSAN instrumentation

- - - - -
0550072f by Ben Gamari at 2023-06-23T16:22:32-04:00
codeGen/tsan: Rework handling of spilling

- - - - -
6f2f4e18 by Ben Gamari at 2023-06-23T16:22:32-04:00
codeGen: Ensure that TSAN is aware of writeArray# write barriers

- - - - -
c32e4e2e by Ben Gamari at 2023-06-23T16:22:32-04:00
codeGen: Ensure that array reads have necessary barriers

This was the cause of #23541.

- - - - -
d2201622 by Ben Gamari at 2023-06-23T16:22:32-04:00
Wordsmith TSAN Note

- - - - -
7bbf8245 by Ben Gamari at 2023-06-23T16:22:32-04:00
codeGen: Use relaxed accesses in ticky bumping

- - - - -
0c18f3ff by Ben Gamari at 2023-06-23T16:22:32-04:00
codeGen: Use relaxed-read in closureInfoPtr

- - - - -
083c7b4c by Ben Gamari at 2023-06-23T16:22:32-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.

- - - - -
27b51df9 by Ben Gamari at 2023-06-23T16:22:32-04:00
STM: Use acquire loads when possible

Full sequential consistency is not needed here.

- - - - -
352c52ac by Ubuntu at 2023-06-23T16:22:32-04:00
ghc-prim: Use C11 atomics

- - - - -
37d24c44 by Ubuntu at 2023-06-23T16:22:32-04:00
Run script

- - - - -
6efff2e0 by Ben Gamari at 2023-06-23T16:22:32-04:00
hadrian: Ensure that way-flags are passed to CC

Previously the way-specific compilation flags (e.g. `-DDEBUG`,
`-DTHREADED_RTS`) would not be passed to the CC invocations. This meant
that C dependency files would not correctly reflect
dependencies predicated on the way, resulting in the rather
painful #23554.

Closes #23554.

- - - - -
64c18366 by Ben Gamari at 2023-06-23T16:22:32-04:00
rts/Interpreter: Fix data race

- - - - -
7fb9ef15 by Ben Gamari at 2023-06-23T16:22:32-04:00
rts/Messages: Fix data race

- - - - -
b1c2cbb9 by Ben Gamari at 2023-06-23T16:22:32-04:00
rts/Prof: Fix data race

- - - - -
20a46f28 by Ben Gamari at 2023-06-23T16:22:32-04:00
rts: Fix various data races

- - - - -
555d054a by Ben Gamari at 2023-06-23T16:22:32-04:00
rts: Use fence rather than redundant load

- - - - -
02a6b271 by Ben Gamari at 2023-06-23T16:22:32-04:00
codeGen: More precise barriers for eager blackholing

- - - - -
6093adb7 by Ben Gamari at 2023-06-23T16:22:32-04:00
testsuite: Add AtomicModifyIORef test

- - - - -


30 changed files:

- compiler/GHC/Cmm/Info.hs
- compiler/GHC/Cmm/ThreadSanitizer.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
- hadrian/src/Settings/Builders/Common.hs
- hadrian/src/Settings/Builders/Ghc.hs
- hadrian/src/Settings/Packages.hs
- + libraries/base/tests/AtomicModifyIORef.hs
- libraries/base/tests/all.T
- libraries/ghc-prim/cbits/atomic.c
- rts/Apply.cmm
- rts/Compact.cmm
- rts/Exception.cmm
- rts/Heap.c
- 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/ThreadPaused.c
- rts/Threads.c
- rts/TraverseHeap.c
- rts/Updates.cmm


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/0d2e7625a71e9a29b32de05e06422f965a13661d...6093adb74d77096b8053910cd81d1f2116bd47c3

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/0d2e7625a71e9a29b32de05e06422f965a13661d...6093adb74d77096b8053910cd81d1f2116bd47c3
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/20230623/b8532f39/attachment-0001.html>

More information about the ghc-commits mailing list