[PATCH] D115078: Split the locking of the queue and the threads vector in the ThreadPool implementation
Benoit Jacob via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Dec 3 19:24:35 PST 2021
Benoit accepted this revision.
Benoit added inline comments.
This revision is now accepted and ready to land.
================
Comment at: llvm/include/llvm/Support/ThreadPool.h:45
+ : Strategy(S), MaxThreadCount(S.compute_thread_count()) {
+ Threads.reserve(MaxThreadCount);
+ }
----------------
is the performance benefit of avoiding some small mallocs worth the line of code?
================
Comment at: llvm/lib/Support/ThreadPool.cpp:27
return; // Already hit the max thread pool size.
- if (ActiveThreads + Tasks.size() <= Threads.size())
- return; // We have enough threads for now.
- int ThreadID = Threads.size();
- Threads.emplace_back([this, ThreadID] {
- Strategy.apply_thread_strategy(ThreadID);
- while (true) {
- std::function<void()> Task;
- {
- std::unique_lock<std::mutex> LockGuard(QueueLock);
- // Wait for tasks to be pushed in the queue
- QueueCondition.wait(LockGuard,
- [&] { return !EnableFlag || !Tasks.empty(); });
- // Exit condition
- if (!EnableFlag && Tasks.empty())
- return;
- // Yeah, we have a task, grab it and release the lock on the queue
+ requested = std::min<int>(requested, MaxThreadCount);
+ while (requested > static_cast<int>(Threads.size())) {
----------------
how about using a new variable instead of mutating `requested`?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D115078/new/
https://reviews.llvm.org/D115078
More information about the llvm-commits
mailing list