public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Zhu, Lipeng" <lipeng.zhu@intel.com>
To: Thomas Koenig <tkoenig@netcologne.de>,
	Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Cc: "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	"Lu, Hongjiu" <hongjiu.lu@intel.com>,
	"Li, Tianyou" <tianyou.li@intel.com>,
	"Deng, Pan" <pan.deng@intel.com>,
	"Guo, Wangyang" <wangyang.guo@intel.com>,
	Jakub Jelinek <jakub@redhat.com>
Subject: RE: [PATCH v4] libgfortran: Replace mutex with rwlock
Date: Fri, 18 Aug 2023 03:06:51 +0000	[thread overview]
Message-ID: <PH7PR11MB60564335B16B69E7F912CC619F1BA@PH7PR11MB6056.namprd11.prod.outlook.com> (raw)
In-Reply-To: <93b9e2d5-4355-136a-a961-da1ae9c1468f@netcologne.de>

Hi Thomas,

> 
> 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.
> 

Yes, the implementation use the read-preferring strategy, and comments in code.
When adding the test cases, I didn’t meet the situation which may cause the deadlock.
Maybe you can give more guidance about that.

> 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.
> 

Sure, as your comments, in the patch V6, I added 3 test cases with OpenMP to test different cases in concurrency respectively:
1. find and create unit very frequently to stress read lock and write lock.
2. only access the unit which exist in cache to stress read lock.
3. access the same unit in concurrency.
For the third test case, it also help to find a bug:  When unit can't be found in cache nor unit list in read phase, then threads will try to acquire write lock to insert the same unit, this will cause duplicate key error.  
To fix this bug, I get the unit from unit list once again before insert in write lock. More details you can refer the patch v6.

> 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
> 

Best Regards,
Lipeng Zhu

  reply	other threads:[~2023-08-18  3:06 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09  2:32 Zhu, Lipeng
2023-05-16  7:08 ` Zhu, Lipeng
2023-05-23  2:53   ` Zhu, Lipeng
2023-05-24 19:18     ` Thomas Koenig
2023-08-18  3:06       ` Zhu, Lipeng [this message]
2023-09-14  8:33         ` Zhu, Lipeng
2023-10-23  1:21           ` Zhu, Lipeng
2023-10-23  5:52             ` Thomas Koenig
2023-10-23 23:59               ` Zhu, Lipeng
2023-11-01 10:14                 ` Zhu, Lipeng
2023-11-02  9:58                   ` Bernhard Reutner-Fischer
2023-11-23  9:36                     ` Zhu, Lipeng
2023-12-07  5:18                       ` Zhu, Lipeng
2023-08-18  3:18       ` [PATCH v6] " Zhu, Lipeng
2023-12-08 10:19         ` Jakub Jelinek
2023-12-09 15:13           ` Zhu, Lipeng
2023-12-09 15:39             ` [PATCH v7] " Lipeng Zhu
2023-12-09 15:23               ` Jakub Jelinek
2023-12-10  3:25                 ` Zhu, Lipeng
2023-12-11 17:45                   ` H.J. Lu
2023-12-12  2:05                     ` Zhu, Lipeng
2023-12-13 20:52                       ` Thomas Schwinge
2023-12-14  2:28                         ` Zhu, Lipeng
2023-12-14 12:29                           ` Thomas Schwinge
2023-12-14 12:39                             ` Jakub Jelinek
2023-12-15  5:43                               ` Zhu, Lipeng
2023-12-21 11:42                         ` Thomas Schwinge
2023-12-22  6:48                           ` Lipeng Zhu
2024-01-03  9:14                           ` Lipeng Zhu
2024-01-17 13:25                             ` Lipeng Zhu
2023-12-14 15:50               ` Richard Earnshaw (lists)
2023-12-15 11:31                 ` Lipeng Zhu
2023-12-15 19:23                   ` Richard Earnshaw
2024-01-02 11:57                     ` Vaseeharan Vinayagamoorthy
2024-01-03  1:02                       ` Lipeng Zhu
  -- strict thread matches above, loose matches on Subject: below --
2023-05-25 12:40 [PATCH v4] " Zhu, Lipeng
     [not found] <20230424214534.77117b73 () nbbrfq>
2023-05-08  9:44 ` Lipeng Zhu
2023-05-08 10:28   ` Bernhard Reutner-Fischer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=PH7PR11MB60564335B16B69E7F912CC619F1BA@PH7PR11MB6056.namprd11.prod.outlook.com \
    --to=lipeng.zhu@intel.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=hongjiu.lu@intel.com \
    --cc=jakub@redhat.com \
    --cc=pan.deng@intel.com \
    --cc=rep.dot.nop@gmail.com \
    --cc=tianyou.li@intel.com \
    --cc=tkoenig@netcologne.de \
    --cc=wangyang.guo@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).