From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by sourceware.org (Postfix) with ESMTPS id 6A98B3858D32; Thu, 25 May 2023 12:40:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6A98B3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1685018421; x=1716554421; h=message-id:date:mime-version:subject:to:cc:from: content-transfer-encoding; bh=5DthwWc8vCT3hP3QF0fCj4LnrU3E3pSnFd54ulZP+Ac=; b=f0GRzwo20FScNHn4AaMoLCtjmyEGaacE83z9Dmhhg8zzG+0b9TcjgIFQ vWVaoBohz1Qmfs7K6lgYXam/Ez0QJS8CEgE73xWWXIsQ0O3cL/fF8PXxv S04Mqm27Z9Nx/MIlTd06yJnSeR55oEY3S6+/sMCvtiM107i1oenU77zIg V4o63qKdkOTfeNJ5dXbClTXkDMSBwXYAjkficbXuztU6woGn+WruglW+0 gNLz7kBxD8voesX1UqUDnp0lalixt6rTovNYZRUyYt7JIIEPN9ezT51PB zJOLtEvuV1ZHBqPH7rAjsDX5EZx59Bx3Ly3Ape0MFy1GugD4U25ZB1Blh A==; X-IronPort-AV: E=McAfee;i="6600,9927,10721"; a="357100357" X-IronPort-AV: E=Sophos;i="6.00,191,1681196400"; d="scan'208";a="357100357" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 May 2023 05:40:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10721"; a="707996106" X-IronPort-AV: E=Sophos;i="6.00,191,1681196400"; d="scan'208";a="707996106" Received: from zhulipeng-win.ccr.corp.intel.com (HELO [10.254.214.68]) ([10.254.214.68]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 May 2023 05:40:17 -0700 Message-ID: <23405f0b-f2b0-86b2-c40c-96156908c02e@intel.com> Date: Thu, 25 May 2023 20:40:15 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.11.0 Subject: Re: [PATCH v4] libgfortran: Replace mutex with rwlock Content-Language: en-US To: Thomas Koenig Cc: fortran@gcc.gnu.org, gcc-patches@gcc.gnu.org, rep.dot.nop@gmail.com, hongjiu.lu@intel.com, tianyou.li@intel.com, pan.deng@intel.com, jakub@redhat.com, wangyang.guo@intel.com From: "Zhu, Lipeng" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FAKE_REPLY_A1,SPF_HELO_NONE,SPF_NONE,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: On 1/1/1970 8:00 AM, Thomas Koenig wrote: > 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. Hi Thomas, Thanks for your time for the review. Sure, I will add test case according to your suggestions and update the comment based on the implementation of "read-preferring" strategy. Thanks, Lipeng Zhu > > 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 > >