[Mlir-commits] [lldb] [llvm] [mlir] Split the llvm::ThreadPool into an abstract base class and an implementation (PR #82094)

Mehdi Amini llvmlistbot at llvm.org
Tue Feb 27 12:25:24 PST 2024


================
@@ -227,7 +265,7 @@ class ThreadPool {
 class ThreadPoolTaskGroup {
----------------
joker-eph wrote:

> Wouldn't the implemention for ThreadPoolTaskGroup come in hand with the one for ThreadPool? 

Right now the only thing the TaskGroup provide is a unique ID in the form of its own address.
I don't quite get what I would change in the implementation? Would you want the group to customize its own `wait()`? Right now it dispatches to the threadpool implementation: `wait(ThreadPoolTaskGroup &Group)`.

Customizing the task group would require to change the pattern at every use site as well: https://github.com/llvm/llvm-project/blob/0e0bee26e7f33c065eebef9a674b2f19bb156414/mlir/include/mlir/IR/Threading.h#L69-L70

Instead of:
```
  llvm::ThreadPool &threadPool = context->getThreadPool();
  llvm::ThreadPoolTaskGroup tasksGroup(threadPool);
```
we would need to use the pool as a factory somehow:
```
  llvm::ThreadPool &threadPool = context->getThreadPool();
  std::unique_ptr<llvm::ThreadPoolTaskGroup> tasksGroup = threadPool.createTaskGroup();
```

I'm not opposed to this, but that still seems like a separate change, and one that would better be done when there is somehow with the need for this.

https://github.com/llvm/llvm-project/pull/82094


More information about the Mlir-commits mailing list