[Lldb-commits] [PATCH] D48393: Make DWARFParsing more thread-safe

Frederic Riss via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Wed Jun 20 15:14:42 PDT 2018


friss added a comment.

In https://reviews.llvm.org/D48393#1138398, @zturner wrote:

> Long term I think one potentially interesting possibility for solving a lot of these threading and lazy evaluation issues is to make a task queue that runs all related operations on a single thread and returns a future you can wait on.  This way, the core data structures themselves do not need synchronization because they are only ever accessed from one thread.  I actually have a patch in progress <https://reviews.llvm.org/D48240> to make this kind of infrastructure, which I actually needed for a different reason, but it would work equally well here.
>
> Mostly just putting this out there as an idea for down the road, not that you should do it right now.


It's an interesting idea, which comes with a couple of tradeoffs:

- We would be essentially serializing the DWARF parsing. I do not know if it needs to be a goal that we're able to do efficient multi-threaded parsing, but it's an obvious consequence which would need to be discussed.
- I have worked on a codebase relying heavily of serialized thread queues and something equivalent to futures to schedule work. Let's say that it was... interesting to debug. If we did this, we don't need to go to the same extremes though. (Also I'm wondering, would tasks running serially be allowed to enqueue other tasks and wait for them? Or would this be forbidden?)

I like the simplification aspect of it though. It is basically equivalent to adding locks at a higher abstraction level than the data-structures like I did. I was pondering that too, but I wasn't sure 1/ which level would be best and 2/ how to be sure I was not going to deadlock the whole thing.


https://reviews.llvm.org/D48393





More information about the lldb-commits mailing list