From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cc-smtpout1.netcologne.de (cc-smtpout1.netcologne.de [89.1.8.211]) by sourceware.org (Postfix) with ESMTPS id 231D83858D28; Wed, 24 May 2023 19:18:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 231D83858D28 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 67F01129F1; Wed, 24 May 2023 21:18:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1684955904; bh=bUdFEN/IyV05JtheQOJjHo5+UWT+LXk6XDV0J8JC+iw=; h=Message-ID:Date:Subject:To:Cc:References:From:In-Reply-To:From; b=lpX0VVDzGuxOeaWqZqCDyg4tz7MUglwaFZdfPNgGK/ZChnn8nogPNdeys7W4JGrms WgYfbtIM9oVo2QitcYuYFmJTJfxAGxrgjz3qmXdhTaMgwdbEL8+oj7haqBsCWFGQQP eRcUKgfpXJxLO2R+1gyjYfRq67bnHbLRxV8aMN8JyeAdQFOmtePN0L+XRukLHeAUGN NFb22k5KbQQxcN5ZfJRjlKEJEal1chF/H9Y6XN4D9mmLK6z5EU+0jGBrnf2GqCqx1Q mNALj22B4OWCwj61rY5TMOBL4Yl7999vCLORt2/0qf60qZpUBcS3hS19JHqlrVXe3r Qf6LnoD0jxwJQ== Received: from [IPV6:2001:4dd7:cfc:0:7285:c2ff:fe6c:992d] (2001-4dd7-cfc-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de [IPv6:2001:4dd7:cfc: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 965AD11DCF; Wed, 24 May 2023 21:18:15 +0200 (CEST) Message-ID: <93b9e2d5-4355-136a-a961-da1ae9c1468f@netcologne.de> Date: Wed, 24 May 2023 21:18:15 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v4] libgfortran: Replace mutex with rwlock To: "Zhu, Lipeng" , Bernhard Reutner-Fischer Cc: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org, hongjiu.lu@intel.com, tianyou.li@intel.com, pan.deng@intel.com, wangyang.guo@intel.com, Jakub Jelinek References: <81c359ae-ab69-7f03-f113-4b865441de44@intel.com> <9e30db8a-2a6f-89d0-84fb-2f549f61954c@intel.com> Content-Language: en-US From: Thomas Koenig In-Reply-To: <9e30db8a-2a6f-89d0-84fb-2f549f61954c@intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-NetCologne-Spam: L X-Rspamd-Action: no action X-Rspamd-Queue-Id: 965AD11DCF X-Spamd-Bar: - X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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, > May I know any comment or concern on this patch, thanks for your time 😄 Thanks for your patience in getting this reviewed. A few remarks / questions. Which strategy is used in this implementation, read-preferring or write-preferring? And if read-preferring is used, is there a danger of deadlock if people do unreasonable things? Maybe you could explain that, also in a comment in the code. Can you add some sort of torture test case(s) which does a lot of opening/closing/reading/writing, possibly with asynchronous I/O and/or pthreads, to catch possible problems? If there is a system dependency or some race condition, chances are that regression testers will catch this. With this, the libgfortran parts are OK, unless somebody else has more comments, so give this a couple of days. I cannot approve the libgcc parts, that would be somebody else (Jakub?) Best regards Thomas