linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luc Maranget <luc.maranget@inria.fr>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Luc Maranget <luc.maranget@inria.fr>,
	Boqun Feng <boqun.feng@gmail.com>,
	Andrea Parri <parri.andrea@gmail.com>,
	Jade Alglave <j.alglave@ucl.ac.uk>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: More on reader-writer locks
Date: Wed, 26 Feb 2020 10:46:37 +0100	[thread overview]
Message-ID: <20200226094637.rhli3jjuiim2noke@yquem.inria.fr> (raw)
In-Reply-To: <Pine.LNX.4.44L0.2002251608290.1485-100000@iolanthe.rowland.org>

Hi all,

As far as I understand there is a contradiction between having a "platonic"
implementation of locks (à la lock.cat) and a concrete one (for ordinary locks
lock -> load acquire, unlock -> store release, + loop [difficult for herd]
or filter clause).

So if reader/writer locks are catified in a platonic way, we cannot
use various atomic primitives. Instead, we give them an abstract semantics
based upon some axiomatisation of their semantics, using cat means.
Such an axionatisation  does not seem straightforward because,
by constrast with locks, there is an integer count
hiddden, and not a simple boolean as for ordinary locks

Some idea would be first to partition reader crtical sections,
and then for each such partition, order elements of the partition and
writer critical section. For one such choice there are still many possible
rf relations...

--Luc

rf relation 
> On Tue, 25 Feb 2020, Luc Maranget wrote:
> 
> > Hi,
> > 
> > As far as I can remember I have implemented atomic_add_unless in herd7.
> 
> Luc, have you considered whether we can use atomic_add_unless and
> cmpxchg to implement reader-writer locks in the LKMM?  I don't think we
> can handle them the same way we handle ordinary locks now.
> 
> Let's say that a lock variable holds 0 if it is unlocked, -1 if it is 
> write-locked, and a positive value if it is read-locked (the value is 
> the number of read locks currently in effect).  Then operations like 
> write_lock, write_trylock, and so on could all be modeled using 
> variants of atomic_add_unless, atomic_dec, and cmpxchg.
> 
> But will that work if the reads-from relation is computed by the cat 
> code in lock.cat?  I suspect it won't.
> 
> How would you approach this problem?
> 
> Alan

  reply	other threads:[~2020-02-26  9:46 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-14  4:01 [RFC 0/3] tools/memory-model: Add litmus tests for atomic APIs Boqun Feng
2020-02-14  4:01 ` [RFC 1/3] Documentation/locking/atomic: Fix atomic-set litmus test Boqun Feng
2020-02-14  4:01 ` [RFC 2/3] tools/memory-model: Add a litmus test for atomic_set() Boqun Feng
2020-02-14  8:12   ` Andrea Parri
2020-02-14 10:40     ` Boqun Feng
2020-02-25  7:34       ` Boqun Feng
2020-02-25 13:01         ` Luc Maranget
2020-02-25 21:42           ` More on reader-writer locks Alan Stern
2020-02-26  9:46             ` Luc Maranget [this message]
2020-02-26  2:51           ` [RFC 2/3] tools/memory-model: Add a litmus test for atomic_set() Boqun Feng
2020-02-14 15:47   ` Alan Stern
2020-02-14 23:52     ` Boqun Feng
2020-02-17 11:02       ` Peter Zijlstra
2020-02-14  4:01 ` [RFC 3/3] tools/memory-model: Add litmus test for RMW + smp_mb__after_atomic() Boqun Feng
2020-02-14  6:15   ` Boqun Feng
2020-02-14  8:18     ` Andrea Parri
2020-02-14  8:20       ` Boqun Feng
2020-02-14 15:58   ` Alan Stern
2020-02-15  0:09     ` Boqun Feng
2020-02-14  9:55 ` [RFC 0/3] tools/memory-model: Add litmus tests for atomic APIs Peter Zijlstra
2020-02-14 10:20 ` Paul E. McKenney
2020-02-14 15:27 ` Alan Stern
2020-02-14 23:39   ` Boqun Feng
2020-02-15 15:25   ` Paul E. McKenney
2020-02-16  5:43     ` Boqun Feng
2020-02-16 12:06       ` Paul E. McKenney
2020-02-16 16:16         ` Alan Stern
2020-02-17  1:27           ` Boqun Feng

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=20200226094637.rhli3jjuiim2noke@yquem.inria.fr \
    --to=luc.maranget@inria.fr \
    --cc=boqun.feng@gmail.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=parri.andrea@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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 NNTP newsgroup(s).