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

[Zachary Turner via lldb-commits]

Related question: Is the laziness done to save memory, startup time, or
both?
On Thu, Jun 21, 2018 at 7:36 AM Greg Clayton via Phabricator <
reviews at reviews.llvm.org> wrote:

> clayborg added a comment.
>
> In https://reviews.llvm.org/D48393#1138989, @labath wrote:
>
> > I am not sure this will actually solve the problems you are seeing. This
> may avoid corrupting the internal DenseMap data structures, but it will not
> make the algorithm using them actually correct.
> >  For example the pattern in `ParseTypeFromDWARF` is:
> >
> > 1. check the "already parsed map". If the DIE is already parsed then
> you're done.
> > 2. if the map contains the magic "DIE_IS_BEING_PARSED" key, abort
> (recursive dwarf references)
> > 3. otherwise, insert the  "DIE_IS_BEING_PARSED" key into the map
> > 4. do the parsing, which potentially involves recursive
> `ParseTypeFromDWARF` calls
> > 5. insert the parsed type into the map
> >
> >   What you do is make each of the steps (1), (3), (5) atomic
> individually. However, the whole algorithm is not correct unless the whole
> sequence is atomic as a whole. Otherwise, if you have two threads trying to
> parse the same DIE (directly or indirectly), one of them could see the
> intermediate DIE_IS_BEING_PARSED and incorrectly assume that it encountered
> recursive types.
>
>
> We need to make #1 atomic.
> #2 would need to somehow know if the type is already being parsed
> recursively by the current thread. If so, then do what we do now. If not,
> we need a way to wait on the completion of this type so the other parsing
> thread can complete it and put it into the map, at which time we grab the
> right value from the map
> So #6 step would need to be added so after we do put it into the map, we
> can notify other threads that might be waiting
>
> > So, I think that locking at a higher level would be better. Doing that
> will certainly be tricky though...
>
>
>
>
> https://reviews.llvm.org/D48393
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20180621/d3b2d933/attachment.html>