On Tue, Dec 20, 2022 at 7:01 PM Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > > On 2022-12-20 13:29, Joel Fernandes wrote: > > > > > I do want to finish my memory barrier studies of SRCU over the holidays since I have been deep in the hole with that already. Back to the post flip memory barrier here since I think now even that might not be needed… > > I strongly suspect the memory barrier after flip is useless for the same > reasons I mentioned explaining why the barrier before the flip is useless. > > However, we need to double-check that we have memory barriers at the > beginning and end of synchronize_srcu, and between load of "unlock" > counters and load of "lock" counters. > > Where is the barrier at the beginning of synchronize_srcu ? I believe we don't need another memory barrier at the beginning of synchronize_srcu() (but this part of my SRCU study is still pending ;)) . The grace period guarantee (read-side critical sections don't span the GP) is already enforced by the memory barrier between scanning for all unlocks, and scanning for all locks (Paired with corresponding memory barriers on the read-side). Accordingly, before we scan all locks and match lock == unlock, there is an smp_mb(). Why is that not sufficient? Thanks, - Joel > > Thanks, > > Mathieu > > -- > Mathieu Desnoyers > EfficiOS Inc. > https://www.efficios.com >
