summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/tsan/rtl/tsan_mutex.h
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* tsan: fix a crashDmitry Vyukov2016-05-061-0/+1
| | | | | | | | | | | | | Fixes crash reported in: https://bugs.chromium.org/p/v8/issues/detail?id=4995 The problem is that we don't have a processor in a free interceptor during thread exit. The crash was introduced by introduction of Processors. However, previously we silently leaked memory which wasn't any better. llvm-svn: 268782
* tsan: speed up race deduplicationDmitry Vyukov2015-09-031-0/+2
| | | | | | | | | | | | | | | | | | | | | | | Race deduplication code proved to be a performance bottleneck in the past if suppressions/annotations are used, or just some races left unaddressed. And we still get user complaints about this: https://groups.google.com/forum/#!topic/thread-sanitizer/hB0WyiTI4e4 ReportRace already has several layers of caching for racy pcs/addresses to make deduplication faster. However, ReportRace still takes a global mutex (ThreadRegistry and ReportMutex) during deduplication and also calls mmap/munmap (which take process-wide semaphore in kernel), this makes deduplication non-scalable. This patch moves race deduplication outside of global mutexes and also removes all mmap/munmap calls. As the result, race_stress.cc with 100 threads and 10000 iterations become 30x faster: before: real 0m21.673s user 0m5.932s sys 0m34.885s after: real 0m0.720s user 0m23.646s sys 0m1.254s http://reviews.llvm.org/D12554 llvm-svn: 246758
* Remove TSAN_DEBUG in favor of SANITIZER_DEBUG.Alexey Samsonov2015-01-031-1/+1
| | | | llvm-svn: 225111
* tsan: refactor storage of meta information for heap blocks and sync objectsDmitry Vyukov2014-05-291-0/+5
| | | | | | | | | | | | | | | The new storage (MetaMap) is based on direct shadow (instead of a hashmap + per-block lists). This solves a number of problems: - eliminates quadratic behaviour in SyncTab::GetAndLock (https://code.google.com/p/thread-sanitizer/issues/detail?id=26) - eliminates contention in SyncTab - eliminates contention in internal allocator during allocation of sync objects - removes a bunch of ad-hoc code in java interface - reduces java shadow from 2x to 1/2x - allows to memorize heap block meta info for Java and Go - allows to cleanup sync object meta info for Go - which in turn enabled deadlock detector for Go llvm-svn: 209810
* tsan: fix internal deadlock detector for external deadlock detectorDmitry Vyukov2014-02-271-1/+1
| | | | | | we must go deeper! llvm-svn: 202365
* [tsan] add coarse-grained lock around the DeadlockDetector. We can do better ↵Kostya Serebryany2014-02-211-0/+1
| | | | | | than that, but that's a start. llvm-svn: 201861
* [tsan] rudimentary support for deadlock detector in tsan (nothing really ↵Kostya Serebryany2014-02-141-2/+2
| | | | | | works yet except for a single tiny test). Also rename tsan's DeadlockDetector to InternalDeadlockDetector llvm-svn: 201407
* tsan: update mutex table for javaDmitry Vyukov2012-12-211-1/+1
| | | | llvm-svn: 170884
* tsan: java interface implementation skeletonDmitry Vyukov2012-12-201-0/+1
| | | | llvm-svn: 170707
* tsan: add mutexsets to reportsDmitry Vyukov2012-12-061-0/+1
| | | | | | With this change reports say what mutexes the threads hold around the racy memory accesses. llvm-svn: 169493
* [TSan] fix a bunch of warnings reported by pedantic gccAlexey Samsonov2012-09-131-1/+1
| | | | llvm-svn: 163788
* tsan: use stack depot to describe heap blocksDmitry Vyukov2012-08-301-0/+2
| | | | llvm-svn: 162902
* tsan/asan: unify ScopedLockDmitry Vyukov2012-06-291-23/+3
| | | | llvm-svn: 159438
* tsan/asan: unify atomics (move atomics from tsan to sanitizer_common)Dmitry Vyukov2012-06-291-1/+1
| | | | llvm-svn: 159437
* [tsan] First commit of ThreadSanitizer (TSan) run-time library.Kostya Serebryany2012-05-101-0/+98
Algorithm description: http://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerAlgorithm Status: The tool is known to work on large real-life applications, but still has quite a few rough edges. Nothing is guaranteed yet. The tool works on x86_64 Linux. Support for 64-bit MacOS 10.7+ is planned for late 2012. Support for 32-bit OSes is doable, but problematic and not yet planed. Further commits coming: - tests - makefiles - documentation - clang driver patch The code was previously developed at http://code.google.com/p/data-race-test/source/browse/trunk/v2/ by Dmitry Vyukov and Kostya Serebryany with contributions from Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov and Evgeniy Stepanov. llvm-svn: 156542
OpenPOWER on IntegriCloud