summaryrefslogtreecommitdiffstats
path: root/llvm/unittests/Support/ThreadPool.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix uninitialized variable warning. NFC.Simon Pilgrim2019-11-181-2/+1
|
* 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
* Revert "Enable ThreadPool to queue tasks that return values."Zachary Turner2018-06-131-19/+0
| | | | | | | | This is failing to compile when LLVM_ENABLE_THREADS is false, and the fix is not immediately obvious, so reverting while I look into it. llvm-svn: 334658
* Enable ThreadPool to support tasks that return values.Zachary Turner2018-06-131-0/+19
| | | | | | | | | | | | | | | | | | | | | Previously ThreadPool could only queue async "jobs", i.e. work that was done for its side effects and not for its result. It's useful occasionally to queue async work that returns a value. From an API perspective, this is very intuitive. The previous API just returned a shared_future<void>, so all we need to do is make it return a shared_future<T>, where T is the type of value that the operation returns. Making this work required a little magic, but ultimately it's not too bad. Instead of keeping a shared queue<packaged_task<void()>> we just keep a shared queue<unique_ptr<TaskBase>>, where TaskBase is a class with a pure virtual execute() method, then have a templated derived class that stores a packaged_task<T()>. Everything else works out pretty cleanly. Differential Revision: https://reviews.llvm.org/D48115 llvm-svn: 334643
* Remove unused lambda captures. NFCMalcolm Parsons2017-01-131-2/+2
| | | | llvm-svn: 291916
* [ThreadPool] Rollback recent changes until I figure out the breakage.Davide Italiano2016-11-281-0/+16
| | | | llvm-svn: 288018
* [ThreadPool] Simplify the interface. NFCI.Davide Italiano2016-11-281-16/+0
| | | | | | | The callers don't use the return value. Found by Michael Spencer. llvm-svn: 288016
* Use the range variant of find instead of unpacking begin/endDavid Majnemer2016-08-111-6/+4
| | | | | | | | | If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278433
* Fix deadlock in ThreadPool unittest.Eli Friedman2016-06-051-1/+1
| | | | | | | (Yes, this only deadlocks on a computer with a single core; I'm using a virtual machine.) llvm-svn: 271855
* ThreadPool unittests: do not hold mutex when calling condition_variable:notify()Mehdi Amini2015-12-191-11/+11
| | | | | From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 256111
* [unittests] ThreadPool: Remove redundant loop, NFCVedant Kumar2015-12-191-4/+2
| | | | llvm-svn: 256097
* [unittests] ThreadPool: Guard updates to MainThreadReadyVedant Kumar2015-12-191-12/+16
| | | | llvm-svn: 256096
* ThreadPool unittest: reimplement concurrency test, deterministically this time.Mehdi Amini2015-12-191-5/+36
| | | | | | | Follow-up to r256056. From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 256087
* Remove possibility of failures to due race in ThreadPool unittestTeresa Johnson2015-12-181-22/+0
| | | | | | | | Remove all checks that required main thread to run faster than tasks in ThreadPool, and yields which are now unnecessary. This should fix some bot failures. llvm-svn: 256056
* Mark ThreadPool unittests as unsupported on PowerPC64Mehdi Amini2015-12-151-0/+4
| | | | | | | Bots are crashing unexpectingly, see: https://llvm.org/bugs/show_bug.cgi?id=25829 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255633
* ThreadPool unittest: add a rough mechanism to mark UNSUPPORTED on a given ↵Mehdi Amini2015-12-151-5/+53
| | | | | | | platform From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255632
* Fix template parameter pack handling in ThreadPoolTeresa Johnson2015-12-151-0/+14
| | | | | | | Fixes passing of template parameter pack via std::forward and add unittest. llvm-svn: 255617
* Add a C++11 ThreadPool implementation in LLVMMehdi Amini2015-12-151-0/+91
| | | | | | | | | | | | | | | | | | | | | | | | | This is a very simple implementation of a thread pool using C++11 thread. It accepts any std::function<void()> for asynchronous execution. Individual task can be synchronize using the returned future, or the client can block on the full queue completion. In case LLVM is configured with Threading disabled, it falls back to sequential execution using std::async with launch:deferred. This is intended to support parallelism for ThinLTO processing in linker plugin, but is generic enough for any other uses. This is a recommit of r255444 ; trying to workaround a bug in the MSVC 2013 standard library. I think I was hit by: http://connect.microsoft.com/VisualStudio/feedbackdetail/view/791185/std-packaged-task-t-where-t-is-void-or-a-reference-class-are-not-movable Recommit of r255589, trying to please g++ as well. Differential Revision: http://reviews.llvm.org/D15464 From: mehdi_amini <mehdi_amini@91177308-0d34-0410-b5e6-96231b3b80d8> llvm-svn: 255593
* Revert "Add a C++11 ThreadPool implementation in LLVM"Mehdi Amini2015-12-151-91/+0
| | | | | | | This reverts commit r255589. Breaks g++ From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255591
* Add a C++11 ThreadPool implementation in LLVMMehdi Amini2015-12-151-0/+91
| | | | | | | | | | | | | | | | | | | | | | | This is a very simple implementation of a thread pool using C++11 thread. It accepts any std::function<void()> for asynchronous execution. Individual task can be synchronize using the returned future, or the client can block on the full queue completion. In case LLVM is configured with Threading disabled, it falls back to sequential execution using std::async with launch:deferred. This is intended to support parallelism for ThinLTO processing in linker plugin, but is generic enough for any other uses. This is a recommit of r255444 ; trying to workaround a bug in the MSVC 2013 standard library. I think I was hit by: http://connect.microsoft.com/VisualStudio/feedbackdetail/view/791185/std-packaged-task-t-where-t-is-void-or-a-reference-class-are-not-movable Differential Revision: http://reviews.llvm.org/D15464 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255589
* Revert r255444.Nico Weber2015-12-131-91/+0
| | | | | | | | It doesn't build on Windows and broke the Windows LLD and LLDB bots: http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/27693/steps/build_Lld/logs/stdio http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc/builds/13468/steps/build/logs/stdio llvm-svn: 255446
* Add a C++11 ThreadPool implementation in LLVMMehdi Amini2015-12-121-0/+91
This is a very simple implementation of a thread pool using C++11 thread. It accepts any std::function<void()> for asynchronous execution. Individual task can be synchronize using the returned future, or the client can block on the full queue completion. In case LLVM is configured with Threading disabled, it falls back to sequential execution using std::async with launch:deferred. This is intended to support parallelism for ThinLTO processing in linker plugin, but is generic enough for any other uses. Differential Revision: http://reviews.llvm.org/D15464 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 255444
OpenPOWER on IntegriCloud