Re: [PATCH v3 4/8] Lock the demangled hash table

[Pedro Alves <palves@redhat.com>]

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