gdb/dwarf: split dwo_lock in more granular locks

The dwo_lock mutex is used to synchronize access to some dwo/dwp-related
data structures, such as dwarf2_per_bfd::dwo_files and
dwp_file::loaded_{cus,tus}.  Right now the scope of the lock is kind of
coarse.  It is taken in the top-level lookup_dwo_unit function, and held
while the thread:

 - looks up an existing dwo_file in the per-bfd hash table for the given
   id/signature
 - if there's no existing dwo_file, attempt to find a .dwo file, open
   it, build the list of units it contains
 - if a new dwo_file was created, insert it in the per-bfd hash table
 - look up the desired unit in the dwo_file

And something similar for the dwp code path.  This means that two
indexing thread can't read in two dwo files simultaneously.  This isn't
ideal in terms of parallelism.

This patch breaks this lock into 3 more fine grained locks:

 - one lock to access dwarf2_per_bfd::dwo_files
 - one lock to access dwp_file::loaded_{cus,tus}
 - one lock in try_open_dwop_file, where we do two operations that
   aren't thread safe (bfd_check_format and gdb_bfd_record_inclusion)

Unfortunately I don't see a clear speedup on my computer with 8 threads.
But the change shouldn't hurt, in theory, and hopefully this can be a
piece that helps in making GDB scale better on machines with many cores
(if we ever bump the max number of worker threads).

This patch uses "double-checked locking" to avoid holding the lock(s)
for the whole duration of reading in dwo files.  The idea is, when
looking up a dwo with a given name:

 - with the lock held, check for an existing dwo_file with that name in
   dwarf2_per_bfd::dwo_files, if found return it
 - if not found, drop the lock, load the dwo file and create a dwo_file
   describing it
 - with the lock held, attempt to insert the new dwo_file in
   dwarf2_per_bfd::dwo_files.  If an entry exists, it means another
   thread simultaneously created an equivalent dwo_file, but won the
   race.  Drop the new dwo_file and use the existing one.  The new
   dwo_file is automatically deleted, because it is help by a unique_ptr
   and the insertion into the unordered_set fails.

Note that it shouldn't normally happen for two threads to look up a dwo
file with the same name, since different units will point to different
dwo files.  But it were to happen, we handle it.  This way of doing
things allows two threads to read in two different dwo files
simulatenously, which in theory should help get better parallelism.  The
same technique is used for dwp_file::loaded_{cus,tus}.

I have some local CI jobs that run the fission and fission-dwp boards,
and I haven't seen regressions.  In addition to the regular testing, I
ran a few tests using those boards on a ThreadSanitizer build of GDB.

Change-Id: I625c98b0aa97b47d5ee59fe22a137ad0eafc8c25
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

0 files changed, 0 insertions, 0 deletions