On Thu, May 23, 2024 at 07:50:11PM -0700, Boqun Feng wrote:
> On Thu, May 23, 2024 at 09:38:05PM -0400, Alan Stern wrote:
> > On Thu, May 23, 2024 at 08:14:38AM -0700, Boqun Feng wrote:
> > > Besides, I'm not sure this is a good idea. Because the "{mb}, {once},
> > > etc" part is a syntax thing, you write a cmpxchg(), it should be
> > > translated to a cmpxchg event with MB tag on. As to failed cmpxchg()
> > > doesn't provide ordering, it's a semantics thing, as Jonas showed that
> > > it can be represent in cat file. As long as it's a semanitc thing and we
> > > can represent in cat file, I don't think we want herd to give a special
> > > treatment.
> >
> > I don't really understand the distinction you're making between
> > syntactic things and semantic things. For most instructions there's no
>
> Syntax is how the code is written, and semantic is how the code is
> executed (in each execution candidate). So if we write a cmpxchg{mb}(),
> and in execution candiates, it could generates a read{MB} event and a
> write{MB} event (succeed case), or a read{MB} event (fail case), "{MB}"
> here doesn't mean it's a full barrier, it only means the event comes
> from a no suffix API. Here "{MB}" only has syntactic meaning (no
> semantic meaning).
Okay, I get it. Then you might agree that it probably would be better
to use a different tag here, because the mb tag is already in use with
other instructions (like smp_mb()) where it does always mean there's a
full barrier.
> Not really, RMW events contains all events generated from
> read-modify-write primitives, if there is an R event without a rmw
> relation (i.e there is no corresponding write event), it's a failed RWM
> by definition: it cannot be anything else.
Not true. An R event without an rmw relation could be a READ_ONCE().
Or a plain read. The memory model uses the tag to distinguish these
cases.
> > that it would work is merely an artifact of herd7's internal actions. I
> > think it would be much cleaner if herd7 represented these events in some
> > other way, particularly if we can tell it how.
> >
> > After all, herd7 already does generate different sets of events for
> > successful (both R and W) and failed (only R) RMWs. It's not such a big
> > stretch to make the R events it generates different in the two cases.
> >
>
> I thought we want to simplify the herd internal processing by avoid
> adding mb events in cmpxchg() cases, in the same spirit, if syntactic
> tagging is already good enough, why do we want to make herd complicate?
Herd7 already is complicated by the fact that it needs to handle
cmpxchg() instructions in two ways: success and failure. This
complication is unavoidable. Adding one extra layer (different tags for
the different ways) is an insignificant increase in the complication,
IMO. And it's a net reduction when you compare it to the amount of
complication currently in the herd7 code.
Also what about cmpxchg_acquire()? If it fails, it will generate an R
event with an acquire tag not in the rmw relation. There is no way to
tell such events apart from a normal smp_load_acquire(), and so the .cat
file would have no way to know that the event should not have acquire
semantics. I guess we would have to rename this tag, as well.
Alan
