On Wed, Mar 03, 2021 at 03:22:46PM -0500, Alan Stern wrote:
> On Wed, Mar 03, 2021 at 09:40:22AM -0800, Paul E. McKenney wrote:
> > On Wed, Mar 03, 2021 at 12:12:21PM -0500, Alan Stern wrote:
>
> > > Local variables absolutely should be treated just like CPU registers, if
> > > possible. In fact, the compiler has the option of keeping local
> > > variables stored in registers.
> > >
> > > (Of course, things may get complicated if anyone writes a litmus test
> > > that uses a pointer to a local variable, Especially if the pointer
> > > could hold the address of a local variable in one execution and a
> > > shared variable in another! Or if the pointer is itself a shared
> > > variable and is dereferenced in another thread!)
> >
> > Good point! I did miss this complication. ;-)
>
> I suspect it wouldn't be so bad if herd7 disallowed taking addresses of
> local variables.
>
> > As you say, when its address is taken, the "local" variable needs to be
> > treated as is it were shared. There are exceptions where the pointed-to
> > local is still used only by its process. Are any of these exceptions
> > problematic?
>
> Easiest just to rule out the whole can of worms.
>
> > > But even if local variables are treated as non-shared storage locations,
> > > we should still handle this correctly. Part of the problem seems to lie
> > > in the definition of the to-r dependency relation; the relevant portion
> > > is:
> > >
> > > (dep ; [Marked] ; rfi)
> > >
> > > Here dep is the control dependency from the READ_ONCE to the
> > > local-variable store, and the rfi refers to the following load of the
> > > local variable. The problem is that the store to the local variable
> > > doesn't go in the Marked class, because it is notated as a plain C
> > > assignment. (And likewise for the following load.)
> > >
> > > Should we change the model to make loads from and stores to local
> > > variables always count as Marked?
> >
> > As long as the initial (possibly unmarked) load would be properly
> > complained about.
>
> Sorry, I don't understand what you mean.
>
> > And I cannot immediately think of a situation where
> > this approach would break that would not result in a data race being
> > flagged. Or is this yet another failure of my imagination?
>
> By definition, an access to a local variable cannot participate in a
> data race because all such accesses are confined to a single thread.
>
> However, there are other aspects to consider, in particular, the
> ordering relations on local-variable accesses. But if, as Luc says,
> local variables are treated just like registers then perhaps the issue
> doesn't arise.
>
> > > What should have happened if the local variable were instead a shared
> > > variable which the other thread didn't access at all? It seems like a
> > > weak point of the memory model that it treats these two things
> > > differently.
> >
> > But is this really any different than the situation where a global
> > variable is only accessed by a single thread?
>
> Indeed; it is the _same_ situation. Which leads to some interesting
> questions, such as: What does READ_ONCE(r) mean when r is a local
> variable? Should it be allowed at all? In what way is it different
> from a plain read of r?
>
> One difference is that the LKMM doesn't allow dependencies to originate
> from a plain load. Of course, when you're dealing with a local
> variable, what matters is not the load from that variable but rather the
> earlier loads which determined the value that had been stored there.
> Which brings us back to the case of the
>
> dep ; rfi
>
> dependency relation, where the accesses in the middle are plain and
> non-racy. Should the LKMM be changed to allow this?
>
For this particular question, do we need to consider code as the follow?
r1 = READ_ONCE(x); // f
if (r == 1) {
local_v = &y; // g
do_something_a();
}
else {
local_v = &y;
do_something_b();
}
r2 = READ_ONCE(*local_v); // e
, do we have the guarantee that the first READ_ONCE() happens before the
second one? Can compiler optimize the code as:
r2 = READ_ONCE(y);
r1 = READ_ONCE(x);
if (r == 1) {
do_something_a();
}
else {
do_something_b();
}
? Although we have:
f ->dep g ->rfi ->addr e
Regards,
Boqun
> There are other differences to consider. For example:
>
> r = READ_ONCE(x);
> smp_wmb();
> WRITE_ONCE(y, 1);
>
> If the write to r were treated as a marked store, the smp_wmb would
> order it (and consequently the READ_ONCE) before the WRITE_ONCE.
> However we don't want to do this when r is a local variable. Indeed, a
> plain store wouldn't be ordered this way because the compiler might
> optimize the store away entirely, leaving the smp_wmb nothing to act on.
>
> So overall the situation is rather puzzling. Treating local variables
> as registers is probably the best answer.
>
> Alan
