mbox series

[0/3] Threads and BFD

Message ID 20231026191435.204144-1-tom@tromey.com
Headers
Series Threads and BFD |

Message

Tom Tromey Oct. 26, 2023, 7:07 p.m. UTC 
  gdb started using threads a while ago.  So far we've (mostly) avoided
doing anything BFD-related off the main thread, but I would like to
change that.

In particular, I'd like gdb to do most of its DWARF reading in the
background.  To achieve this, gdb only really needs threading on a
per-BFD basis.  That is, all access to any particular BFD will be from
a single thread at a given time.  However, due to DWO, gdb may also
need to create a new BFD from a worker thread.

For gdb's purposes, I think only BFD globals really need to be
protected.  There are a few spots to consider.

The first is BFD error handling.  In this series, I chose to make it
thread-local.  This approach seemed simple and straightforward.
Locking seemed impractical here.  Maybe moving the error into a BFD
would work, but I didn't serious investigate that.

The second set of globals involve opening and closing BFD, and also
the fd cache.  I went back and forth on ways to solve this.  In this
series I let the BFD client provide lock- and unlock-functions, and
change BFD to use these when needed.  I took this approach because it
means that current BFD clients don't need to be changed in any way.
(I do have a variant of this patch where BFD implements its own
locking using a POSIX or Windows mutex; I can send that if you'd
prefer.)

I have a larger patch series to implement the background reading in
gdb, based on these patches.  I've run this under TSAN quite a bit and
I think all the races (there were none in BFD, of course) and
deadlocks (I found one in my first draft of this patch) have been
ironed out.  Also, it's worth noting that the approach taken here
won't really affect single-threaded BFD users, i.e., everything except
gdb.

Let me know what you think.

Tom

Comments

Nick Clifton Nov. 1, 2023, 12:26 p.m. UTC | #1 
Hi Tom,

> gdb started using threads a while ago.  So far we've (mostly) avoided
> doing anything BFD-related off the main thread, but I would like to
> change that.

his is definitely a worthy goal.

> The first is BFD error handling.  In this series, I chose to make it
> thread-local.  This approach seemed simple and straightforward.
> Locking seemed impractical here.  Maybe moving the error into a BFD
> would work, but I didn't serious investigate that.

Nah - I am a firm believer in keeping things simple if possible.

> The second set of globals involve opening and closing BFD, and also
> the fd cache.  I went back and forth on ways to solve this.  In this
> series I let the BFD client provide lock- and unlock-functions, and
> change BFD to use these when needed.  I took this approach because it
> means that current BFD clients don't need to be changed in any way.
> (I do have a variant of this patch where BFD implements its own
> locking using a POSIX or Windows mutex; I can send that if you'd
> prefer.)

No, I prefer the approach you have posted here.

Cheers
   Nick