Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 18 Jan 2023 16:11:47 -0800 | From | "Paul E. McKenney" <> | Subject | Re: Internal vs. external barriers (was: Re: Interesting LKMM litmus test) |
| |
On Wed, Jan 18, 2023 at 10:24:50PM +0100, Jonas Oberhauser wrote: > > > On 1/18/2023 10:12 PM, Paul E. McKenney wrote: > > > The only difference between srcu_read_lock() and srcu_read_unlock() > > on the one hand and srcu_down_read() and srcu_up_read() on the other > > is that a matching pair of srcu_read_lock() and srcu_read_unlock() > > must be running on the same task. In contrast, srcu_down_read() and > > srcu_up_read() are not subject to this constraint. > > > > > What I was suggesting below is how to redefine "match" between read_down and > > > read_up that work more like a cross-thread semaphore. > > Understood, but what I don't understand is why not simply this: > > > > let srcu-rscs-down = ([Srcu-down] ; (data | rf)* ; [Srcu-up]) & loc > > Oh, I had thought that it should be more like a semaphore rather than just a > cross-cpu mutex. > > Here's an example of how what you are describing would be used: > > P0{ > idx = srcu_down(&ss); > store_release(done,1); > } > > P1{ > while (! load_acquire(done)); > srcu_up(&ss,idx) > }
Exactly!!!
> What I was thinking of is more something like this: > > P0{ > idx1 = srcu_down(&ss); > srcu_up(&ss,idx1); > } > > P1{ > idx2 = srcu_down(&ss); > srcu_up(&ss,idx2) > }
And srcu_read_lock() and srcu_read_unlock() already do this.
> where the big difference to srcu_lock/unlock would be that if P0 and P1 > happened to get the same index -- which you could very well check or > synchronize on -- that you would be guaranteed that the grace period only > ends once *all* threads that are using this index have called up. (note that > I believe that your implementation has this property, and some users may > come to rely on it if they find out!)
They are permitted and encouraged to rely on the fact that synchronize_srcu() waits until all pre-existing SRCU read-side critical sections have completed, which I believe is quite close to what you are saying. But if they want to look at the return values from either srcu_read_lock() or srcu_down_read(), they would be better off using either get_state_synchronize_srcu() or start_poll_synchronize_srcu().
Huh. I need to add a NUM_ACTIVE_SRCU_POLL_OLDSTATE, don't I? I first need to figure out what its value would be.
> If you want this latter kind of guarantee, then you need to do so something > along the lines of what Alan or I wrote. > > If all you need is the ability to use the first scenario, without any > guarantee that if the index happened to be the same (or providing an API > where you can do the down with a fixed index provided by P0) the grace > period will extend, then what you propose should be right. > > But from Alan's comments I had misunderstood that that wouldn't be the case.
"What do you need?" "Well, what can be provided?" ;-)
Thanx, Paul
| ![\](/images/icornerr.gif) |