From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125498 invoked by alias); 30 May 2019 12:58:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 125487 invoked by uid 89); 30 May 2019 12:58:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*RU:209.85.221.65, HX-Spam-Relays-External:209.85.221.65 X-HELO: mail-wr1-f65.google.com Received: from mail-wr1-f65.google.com (HELO mail-wr1-f65.google.com) (209.85.221.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 May 2019 12:58:53 +0000 Received: by mail-wr1-f65.google.com with SMTP id x4so4166561wrt.6 for ; Thu, 30 May 2019 05:58:53 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:4eeb:42ff:feef:f164? ([2001:8a0:f913:f700:4eeb:42ff:feef:f164]) by smtp.gmail.com with ESMTPSA id t6sm5902085wmt.34.2019.05.30.05.58.50 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 30 May 2019 05:58:50 -0700 (PDT) Subject: Re: [PATCH v3 4/8] Lock the demangled hash table To: Tom Tromey , gdb-patches@sourceware.org References: <20190529212916.23721-1-tom@tromey.com> <20190529212916.23721-5-tom@tromey.com> From: Pedro Alves Message-ID: <25f1c05d-c2ef-d229-1eef-1029186070b3@redhat.com> Date: Thu, 30 May 2019 12:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190529212916.23721-5-tom@tromey.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-05/txt/msg00683.txt.bz2 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 > > * 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 > #include "common/pathstuff.h" > +#if CXX_STD_THREAD > +#include > +#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