On Tue, Jan 24, 2023 at 05:39:53PM +0100, Jonas Oberhauser wrote:
The implementation of synchronize_srcu() has quite a few smp_mb()
On 1/24/2023 5:22 PM, Paul E. McKenney wrote:
I clearly recall someI think even if you implement the unlock as mb() followed by some store that
store-based lack of ordering after a grace period from some years back,
and am thus far failing to reproduce it.
And here is another attempt that herd7 actually does allow.
So what did I mess up this time? ;-)
Thanx, Paul
------------------------------------------------------------------------
C C-srcu-observed-4
(*
* Result: Sometimes
*
* The Linux-kernel implementation is suspected to forbid this.
*)
{}
P0(int *x, int *y, int *z, struct srcu_struct *s)
{
int r1;
r1 = srcu_read_lock(s);
WRITE_ONCE(*y, 2);
WRITE_ONCE(*x, 1);
srcu_read_unlock(s, r1);
}
P1(int *x, int *y, int *z, struct srcu_struct *s)
{
int r1;
WRITE_ONCE(*y, 1);
synchronize_srcu(s);
WRITE_ONCE(*z, 2);
}
P2(int *x, int *y, int *z, struct srcu_struct *s)
{
WRITE_ONCE(*z, 1);
smp_store_release(x, 2);
}
exists (x=1 /\ y=1 /\ z=1)
is read by the gp between mb()s, this would still be allowed.
invocations.
But exactly how are you modeling this? As in what additional accesses
and memory barriers are you placing in which locations?
I have already forgotten the specifics, but I think the power model allowsPowerPC would forbid the 3.2W case, where each process used an
certain stores never propagating somewhere?
smp_store_release() as its sole ordering (no smp_mb() calls at all).
[...]
This propagation is modulated by the memory barriers, though.