summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
*-------------. Merge branches 'wip/tsan/sched', 'wip/tsan/ci', 'wip/tsan/storage', ↵wip/tsan/allBen Gamari2020-11-0853-591/+822
|\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 'wip/tsan/wsdeque', 'wip/tsan/misc', 'wip/tsan/stm', 'wip/tsan/event-mgr', 'wip/tsan/timer' and 'wip/tsan/stats' into wip/tsan/all
| | | | | | | | * rts: Tear down stats_mutex after exitHeapProfilingBen Gamari2020-11-084-5/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the latter wants to call getRTSStats.
| | | | | | | | * rts/Stats: Protect with mutexBen Gamari2020-11-081-3/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While on face value this seems a bit heavy, I think it's far better than enforcing ordering on every access.
| | | | | | | | * rts/Stats: Hide a few unused unnecessarily global functionsBen Gamari2020-11-082-22/+0
| | | | | | | | |
| | | | | | | * | rts: Fix races in Pthread timer backend shudownBen Gamari2020-11-081-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We can generally be pretty relaxed in the barriers here since the timer thread is a loop.
| | | | | | | * | rts: Fix timer initializationBen Gamari2020-11-081-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously `initScheduler` would attempt to pause the ticker and in so doing acquire the ticker mutex. However, initTicker, which is responsible for initializing said mutex, hadn't been called yet.
| | | | | | | * | rts: Pause timer while changing capability countBen Gamari2020-11-083-20/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This avoids #17289.
| | | | | | | * | rts: Accept benign races in ProftimerBen Gamari2020-11-081-5/+5
| | | | | | | |/
| | | | | | * | Mitigate data races in event manager startup/shutdownBen Gamari2020-11-083-21/+33
| | | | | | |/
| | | | | * | rts/stm: Strengthen orderings to SEQ_CST instead of volatileBen Gamari2020-11-082-23/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously the `current_value`, `first_watch_queue_entry`, and `num_updates` fields of `StgTVar` were marked as `volatile` in an attempt to provide strong ordering. Of course, this isn't sufficient. We now use proper atomic operations. In most of these cases I strengthen the ordering all the way to SEQ_CST although it's possible that some could be weakened with some thought.
| | | | | * | rts/STM: Use atomicsBen Gamari2020-11-081-27/+45
| | | | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a potentially harmful race where we failed to synchronize before looking at a TVar's current_value. Also did a bit of refactoring to avoid abstract over management of max_commits.
| | | | * | rts: Use proper relaxe operations in getCurrentThreadCPUTimeGHC GitLab CI2020-11-081-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here we are doing lazy initialization; it's okay if we do the check more than once, hence relaxed operation is fine.
| | | | * | rts: Avoid lock order inversion during forkBen Gamari2020-11-081-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | Fixes #17275.
| | | | * | rts: Use relaxed atomics for whitehole spin statsBen Gamari2020-11-082-3/+3
| | | | |/
| | | * | rts/WSDeque: Rewrite with proper atomicsBen Gamari2020-11-084-174/+111
| | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After a few attempts at shoring up the previous implementation, I ended up turning to the literature and now use the proven implementation, > N.M. Lê, A. Pop, A.Cohen, and F.Z. Nardelli. "Correct and Efficient > Work-Stealing for Weak Memory Models". PPoPP'13, February 2013, > ACM 978-1-4503-1922/13/02. Note only is this approach formally proven correct under C11 semantics but it is also proved to be a bit faster in practice.
| | * | Strengthen ordering in releaseGCThreadsBen Gamari2020-11-081-2/+2
| | | |
| | * | rts: Annotate hopefully "benign" races in freeGroupBen Gamari2020-11-081-0/+25
| | | |
| | * | rts: Use relaxed ordering on spinlock countersBen Gamari2020-11-082-2/+4
| | | |
| | * | rts/SpinLock: Separate out slow pathBen Gamari2020-11-083-10/+47
| | | | | | | | | | | | | | | | | | | | | | | | Not only is this in general a good idea, but it turns out that GCC unrolls the retry loop, resulting is massive code bloat in critical parts of the RTS (e.g. `evacuate`).
| | * | rts: Fix race in GC CPU time accountingGHC GitLab CI2020-11-081-3/+6
| | | | | | | | | | | | | | | | | | | | Ensure that the GC leader synchronizes with workers before calling stat_endGC.
| | * | rts: Join to concurrent mark thread during shutdownBen Gamari2020-11-084-1/+20
| | | | | | | | | | | | | | | | | | | | Previously we would take all capabilities but fail to join on the thread itself, potentially resulting in a leaked thread.
| | * | rts/Storage: Accept races on heap size countersBen Gamari2020-11-081-5/+8
| | | |
| | * | rts: Use RELEASE ordering in unlockClosureBen Gamari2020-11-081-3/+2
| | | |
| | * | rts/GC: Use atomicsBen Gamari2020-11-0811-176/+193
| | | |
| | * | rts/Weak: Eliminate data racesBen Gamari2020-11-082-18/+14
| | | | | | | | | | | | | | | | | | | | By taking all_tasks_mutex in stat_exit. Also better-document the fact that the task statistics are protected by all_tasks_mutex.
| | * | rts/Updates: Use proper atomic operationsBen Gamari2020-11-081-4/+2
| | | |
| | * | rts/Storage: Use atomicsBen Gamari2020-11-081-18/+17
| | | |
| | * | rts: Avoid data races in StablePtr implementationBen Gamari2020-11-082-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes two potentially problematic data races in the StablePtr implementation: * We would fail to RELEASE the stable pointer table when enlarging it, causing other cores to potentially see uninitialized memory. * We would fail to ACQUIRE when dereferencing a stable pointer.
| | * | rts: Rework handling of mutlist scavenging statisticsBen Gamari2020-11-083-37/+83
| | | |
| | * | rts/BlockAlloc: Use relaxed operationsBen Gamari2020-11-081-6/+7
| | |/
| * | testsuite: Mark T13702 as broken with TSAN due to #18884Ben Gamari2020-11-081-1/+4
| | |
| * | testsuite: Mark T3807 as broken with TSANBen Gamari2020-11-081-2/+5
| | | | | | | | | | | | Due to #18883.
| * | TSANUtils: Ensure that C11 atomics are supportedBen Gamari2020-11-081-0/+4
| | |
| * | gitlab-ci: Disable documentation in TSAN buildBen Gamari2020-11-081-0/+3
| | | | | | | | | | | | | | | Haddock chews through enough memory to cause the CI builders to OOM and there's frankly no reason to build documentation in this job anyways.
| * | testsuite: Mark T9872[abc] as high_memory_usageBen Gamari2020-11-081-3/+6
| | | | | | | | | | | | These all have a maximum residency of over 2 GB.
| * | testsuite: Mark hie002 as high_memory_usageBen Gamari2020-11-081-0/+1
| | | | | | | | | | | | | | | This test has a peak residency of 1GByte; this is large enough to classify as "high" in my book.
| * | testsuite: Skip high memory usage tests with TSANBen Gamari2020-11-081-0/+4
| | | | | | | | | | | | | | | ThreadSanitizer significantly increases the memory footprint of tests, so much so that it can send machines into OOM.
| * | testsuite: Skip divbyzero and derefnull under TSANGHC GitLab CI2020-11-081-0/+4
| | | | | | | | | | | | ThreadSanitizer changes the output of these tests.
| * | testsuite: Mark setnumcapabilities001 as broken with TSANGHC GitLab CI2020-11-084-0/+8
| | | | | | | | | | | | Due to #18808.
| * | gitlab-ci: Add nightly-x86_64-linux-deb9-tsan jobBen Gamari2020-11-081-0/+16
| |/
* | rts: Make write of to_cap->inbox atomicBen Gamari2020-11-082-2/+1
| | | | | | | | | | This is necessary since emptyInbox may read from to_cap->inbox without taking cap->lock.
* | Capabiliity: Properly fix data race on n_returning_tasksBen Gamari2020-11-083-4/+16
| | | | | | | | | | There is a real data race but can be made safe by using proper atomic (but relaxed) accesses.
* | Document schedulePushWork raceBen Gamari2020-11-082-34/+70
| |
* | Disable flawed assertionBen Gamari2020-11-081-1/+4
| |
* | rts/Task: Move debugTrace to avoid data raceBen Gamari2020-11-081-2/+2
| | | | | | | | Specifically, we need to hold all_tasks_mutex to read taskCount.
* | rts/RaiseAsync: Synchronize what_next readBen Gamari2020-11-081-1/+1
| |
* | rts/Messages: Annotate benign raceBen Gamari2020-11-081-0/+3
| |
* | rts/Threads: Avoid data races (TODO)Ben Gamari2020-11-081-18/+10
| | | | | | | | | | | | | | | | | | Replace barriers with appropriate ordering. Drop redundant barrier in tryWakeupThread (the RELEASE barrier will be provided by sendMessage's mutex release). We use relaxed operations on why_blocked and the stack although it's not clear to me why this is necessary.
* | rts: Eliminate shutdown data race on task countersBen Gamari2020-11-082-0/+5
| |
* | rts/Schedule: Eliminate data races in run queue managementBen Gamari2020-11-081-3/+12
| |
View Lorry Controller Status