[PATCH v3 4/8] Lock the demangled hash table
Pedro Alves
palves@redhat.com
Thu May 30 12:58:00 GMT 2019
On 5/29/19 10:29 PM, Tom Tromey wrote:
> This introduces a lock that is used when modifying the demangled hash
> table.
>
> gdb/ChangeLog
> 2019-05-29 Tom Tromey <tom@tromey.com>
>
> * symtab.c (demangled_mutex): New global.
> (symbol_set_names): Use a lock_guard.
> ---
> gdb/ChangeLog | 5 ++
> gdb/symtab.c | 134 ++++++++++++++++++++++++++++----------------------
> 2 files changed, 81 insertions(+), 58 deletions(-)
>
> diff --git a/gdb/symtab.c b/gdb/symtab.c
> index 130d5cd48ff..6ad024a8a29 100644
> --- a/gdb/symtab.c
> +++ b/gdb/symtab.c
> @@ -69,6 +69,9 @@
> #include "arch-utils.h"
> #include <algorithm>
> #include "common/pathstuff.h"
> +#if CXX_STD_THREAD
> +#include <mutex>
> +#endif
>
> /* Forward declarations for local functions. */
>
> @@ -709,6 +712,11 @@ symbol_set_language (struct general_symbol_info *gsymbol,
>
> /* Functions to initialize a symbol's mangled name. */
>
> +#if CXX_STD_THREAD
> +/* Mutex that is used when modifying the demangled hash table. */
> +static std::mutex demangled_mutex;
> +#endif
Not just modifying but when accessing as well.
There's only a single mutex, and the comment says _THE_ demangled
hash table, but AFAICS, each per_bfd has its own table, right?
A single lock for every table compared to a lock per table might be
a good approach, but I'd welcome extended comments to explain
that design choice.
Thanks,
Pedro Alves
More information about the Gdb-patches
mailing list