On Tue, Jan 17, 2023 at 07:50:41PM -0800, Paul E. McKenney wrote:
On Tue, Jan 17, 2023 at 03:15:06PM -0500, Alan Stern wrote:It might make sense to work on that first, before trying to do
On Tue, Jan 17, 2023 at 09Here srcu_down_read() and srcu_up_read() are to srcu_read_lock() and
Given an Srcu-down and an Srcu-up:Not at all reasonable.
let srcu-rscs = ( return_value(Srcu-lock) ; (dep | rfi)* ;
parameter(Srcu-unlock, 2) ) |
( return_value(Srcu-down) ; (dep | rf)* ;
parameter(Srcu-up, 2) )
Seem reasonable, or am I missing yet something else?
For one thing, consider this question: Which statements lie inside a
read-side critical section?
srcu_read_unlock() as down_read() and up_read() are to mutex_lock()
and mutex_unlock(). Not that this should be all that much comfort
given that I have no idea how one would go about modeling down_read()
and up_read() in LKMM.
srcu_down_read() and srcu_up_read().
Maybe we don't really need to talk about read-side critical sections atWith srcu_read_lock() and a matching srcu_read_unlock(), the answer isAnd I agree that it must be clearly specified, and my that previous try
clear: All statements po-between the two. With srcu_down_read() and
srcu_up_read(), the answer is cloudy in the extreme.
was completely lacking. Here is a second attempt:
let srcu-rscs = (([Srcu-lock] ; data ; [Srcu-unlock]) & loc) |
(([Srcu-down] ; (data | rf)* ; [Srcu-up]) & loc)
(And I see your proposal and will try it.)
Also, bear in mind that the Fundamental Law of RCU is formulated inOne way of answering this question is by analogy with down() and up()
terms of stores propagating to a critical section's CPU. What are we to
make of this when a single critical section can belong to more than one
CPU?
when used as a cross-task mutex. Another is by mechanically applying
some of current LKMM. Let's start with this second option.
LKMM works mostly with critical sections, but we also discussed ordering
based on the set of events po-after an srcu_read_lock() on the one hand
and the set of events po-before an srcu_read_unlock() on the other.
Starting here, the critical section is the intersection of these two sets.
In the case of srcu_down_read() and srcu_up_read(), as you say, whatever
might be a critical section must span processes. So what if instead of
po, we used (say) xbstar? Then given a set of A such that ([Srcu-down ;
xbstar ; A) and B such that (B ; xbstar ; [Srcu-up]), then the critical
section is the intersection of A and B.
One objection to this approach is that a bunch of unrelated events could
end up being defined as part of the critical section. Except that this
happens already anyway in real critical sections in the Linux kernel.
So what about down() and up() when used as cross-task mutexes?
These often do have conceptual critical sections that protect some
combination of resource, but these critical sections might span tasks
and/or workqueue handlers. And any reasonable definition of these
critical sections would be just as likely to pull in unrelated accesses as
the above intersection approach for srcu_down_read() and srcu_up_read().
But I am just now making all this up, so thoughts?
all. Once again, here's what explanation.txt currently says:
For any critical section C and any grace period G, at least
one of the following statements must hold:
(1) C ends before G does, and in addition, every store that
propagates to C's CPU before the end of C must propagate to
every CPU before G ends.
(2) G starts before C does, and in addition, every store that
propagates to G's CPU before the start of G must propagate
to every CPU before C starts.
Suppose we change this to:
For any RCU lock operation L and matching unlock operation U,
and any matching grace period G, at least one of the following
statements must hold:
(1) U executes before G ends, and in addition, every store that
propagates to U's CPU before U executes must propagate to
every CPU before G ends.
(2) G starts before L executes, and in addition, every store that
propagates to G's CPU before the start of G must propagate
to every CPU before L executes.
(For SRCU, G matches L and U if it operates on the same srcu structure.)
Indeed, given:Indeed, there had better be something else forbidding such executions, or
P0(int *x) {
srcu_down_read(x);
}
P1(int *x) {
srcu_up_read(x);
}
what are we to make of executions in which P1 executes before P0?
this is an invalid use of srcu_down_read() and srcu_up_read().
This mightHmmm. What happens if you write:
become more clear if the example is expanded to include the index returned
from srcu_down_read() that is to be passed to srcu_up_read():
P0(int *x, int *i) {
WRITE_ONCE(i, srcu_down_read(x));
}
P1(int *x, int *i) {
srcu_up_read(x, READ_ONCE(i));
}
r1 = srcu_down_read(x);
r2 = srcu_down_read(x);
srcu_up_read(x, r1);
srcu_up_read(x, r2);
? I can't even tell what that would be _intended_ to do.