From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout1.netcologne.de (cc-smtpout1.netcologne.de [IPv6:2001:4dd0:100:1062:25:2:0:1]) by sourceware.org (Postfix) with ESMTPS id 07A163858D37; Wed, 28 Dec 2022 09:25:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 07A163858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=netcologne.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=netcologne.de Received: from cc-smtpin1.netcologne.de (cc-smtpin1.netcologne.de [89.1.8.201]) by cc-smtpout1.netcologne.de (Postfix) with ESMTP id 60F9411F19; Wed, 28 Dec 2022 10:24:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1672219499; bh=VSn0mNCL1O4VhodHCglAhoP2K4WC741eayOwSk3vO8M=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:From; b=o1QTiBn6yzFUdCWLAd7D1M0luZhmxCk3DfJFV4v3q7ok/cHdbUs33CfcArVc2Ifbl LTm8eCSCPwyYvtX40ye9cuXEVpG12KmONulc4LNgM3RV87JV2l/oatswBoeojTNjgx ieJPryU7IjOuGe3ypBJQtnAcRjVchpPeViir6XPH30o83OHN6zfUZQElbhc84+93Dd D93UXJajnVkCijiRRjz0cQRfaQ0szlwRpj8/vyD+NwATEfpgmkiPj01c6jZgteSxPn XOhauKwj0nZ+rbCQp+chUPcaAPT0p5LXM5fh2o3+tOMDNHICuset0PHO7C9Z7Xfawd gHOovoM1cAGJA== Received: from [IPV6:2a0a:a540:f43:0:7285:c2ff:fe6c:992d] (2a0a-a540-f43-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de [IPv6:2a0a:a540:f43:0:7285:c2ff:fe6c:992d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by cc-smtpin1.netcologne.de (Postfix) with ESMTPSA id CBDBC11D85; Wed, 28 Dec 2022 10:24:53 +0100 (CET) Message-ID: <1051672f-91ff-f9f8-50e8-c44df16b2bd8@netcologne.de> Date: Wed, 28 Dec 2022 10:24:53 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH v2] libgfortran: Replace mutex with rwlock To: Lipeng Zhu , fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org Cc: hongjiu.lu@intel.com, tianyou.li@intel.com, pan.deng@intel.com References: <20221230001607.2232962-1-lipeng.zhu@intel.com> Content-Language: en-US From: Thomas Koenig In-Reply-To: <20221230001607.2232962-1-lipeng.zhu@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-NetCologne-Spam: L X-Rspamd-Queue-Id: CBDBC11D85 X-Spamd-Bar: - X-Rspamd-Action: no action X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Lipeng, > This patch try to introduce the rwlock and split the read/write to > unit_root tree and unit_cache with rwlock instead of the mutex to > increase CPU efficiency. In the get_gfc_unit function, the percentage > to step into the insert_unit function is around 30%, in most instances, > we can get the unit in the phase of reading the unit_cache or unit_root > tree. So split the read/write phase by rwlock would be an approach to > make it more parallel. No comment on the code itself, as yet... but I'd like to know how throroughly you tested it, using which tools, and on which programs. Did you use valgrind --tool=helgrind or --tool=drd? Since it is prone to race conditions, did you also test Fortran's asynchronous I/O? Best regards Thomas