Add an assertion that parallelForEach doesn't nest.
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 30598 Build 30597: arc lint + arc unit
Event Timeline
This will be nice to prevent bugs in the future. Should it be behind #ifndef NDEBUG though? Presumably if assertions are disabled then this bug would be expected to be undefined behavior and avoid the overhead of the thread local variable, is that right?
If you worry about the cost of assigning a boolean value to the thread-local variable, I'd think that's really cheap and negligible. This function is not called too casually, because distributing jobs to threads waiting in the thread pool is not cheap. Compared to that, these assignments are virtually nothing.
lld/Common/Threads.cpp | ||
---|---|---|
13 | This doesn't have to be thread_local. This is a fundamental problem of TaskGroup. template <class IterTy, class FuncTy> void parallel_for_each(IterTy Begin, IterTy End, FuncTy Fn) { TaskGroup TG; .... // In ~Latch called by ~TaskGroup, all threads of the default executor can block on different `std::mutex`es if there are multiple concurrent `parallel_for_each` invocations. } It doesn't need nested parallel_for_each to get stuck. It just needs more concurrent parallel_for_each invocations than the number of executors. |
lld/Common/Threads.cpp | ||
---|---|---|
13 | The code (with thread_local bool -> std::atomic<bool>) can probably be moved to include/llvm/Support/Parallel.h before it gets improved to allow concurrent invocations. |
lld/Common/Threads.cpp | ||
---|---|---|
13 | Do you think you can fix the function so that parallel_for_each is reentrant? If so, do you mind if I ask you do that? |
This doesn't have to be thread_local. This is a fundamental problem of TaskGroup.
It doesn't need nested parallel_for_each to get stuck. It just needs more concurrent parallel_for_each invocations than the number of executors.