Fix a lost-wakeup bug in BLACKHOLE handling (#13751)
Summary: The problem occurred when * Threads A & B evaluate the same thunk * Thread A context-switches, so the thunk gets blackholed * Thread C enters the blackhole, creates a BLOCKING_QUEUE attached to the blackhole and thread A's `tso->bq` queue * Thread B updates the blackhole with a value, overwriting the BLOCKING_QUEUE * We GC, replacing A's update frame with stg_enter_checkbh * Throw an exception in A, which ignores the stg_enter_checkbh frame Now we have C blocked on A's tso->bq queue, but we forgot to check the queue because the stg_enter_checkbh frame has been thrown away by the exception. The solution and alternative designs are discussed in Note [upd-black-hole]. This also exposed a bug in the interpreter, whereby we were sometimes context-switching without calling `threadPaused()`. I've fixed this and added some Notes. Test Plan: * `cd testsuite/tests/concurrent && make slow` * validate Reviewers: niteria, bgamari, austin, erikd Reviewed By: erikd Subscribers: rwbarton, thomie GHC Trac Issues: #13751 Differential Revision: https://phabricator.haskell.org/D3630
Showing
- includes/stg/MiscClosures.h 0 additions, 2 deletionsincludes/stg/MiscClosures.h
- rts/HeapStackCheck.cmm 0 additions, 24 deletionsrts/HeapStackCheck.cmm
- rts/Interpreter.c 10 additions, 0 deletionsrts/Interpreter.c
- rts/Messages.c 3 additions, 1 deletionrts/Messages.c
- rts/Schedule.c 3 additions, 4 deletionsrts/Schedule.c
- rts/StgStartup.cmm 3 additions, 0 deletionsrts/StgStartup.cmm
- rts/sm/Evac.c 63 additions, 1 deletionrts/sm/Evac.c
- rts/sm/Evac.h 3 additions, 0 deletionsrts/sm/Evac.h
- rts/sm/Scav.c 47 additions, 23 deletionsrts/sm/Scav.c
- testsuite/tests/concurrent/should_run/all.T 1 addition, 0 deletionstestsuite/tests/concurrent/should_run/all.T
Loading
Please register or sign in to comment