On Mon, Feb 27, 2023 at 9:39 AM Jonas Oberhauser
<jonas.oberhauser@xxxxxxxxxxxxxxx> wrote:
Making less likely still sounds like a win to me.
On 2/26/2023 5:23 PM, Joel Fernandes wrote:
On Fri, Feb 24, 2023 at 02:52:51PM +0100, Jonas Oberhauser wrote:I had thought about going in that direction, but it doesn't prevent
[...]Alternatively can be the following appended diff? Requires only single 'int'
in ->ppo then and prevents future similar issues caused by sub relations.
Also makes clear that ->ppo can only be CPU-internal.
future similar issues, at best makes them less likely.
For example, you could have an xfence that somehow goes back to theI am not sure I understand, what is the problem with enforcing that
original thread, but to a po-earlier event (e.g., like prop).
Given that to-r and to-w are unlikely to ever become become inconsistent
with po, I am not sure it even really helps much.
ppo is only supposed to ever be -int ? Sounds like it makes it super
clear.
Personally I'm not too happy with the ad-hoc '& int' because it's likeSo, with the idea I suggest, you will have fewer ints so you should be happy ;-)
adding some unused stuff (via ... | unused-stuff) and then cutting itI see. Ok, I'll defer to your expertise on this since you know more
back out with &int, unlike prop & int which has a real semantic meaning
(propagate back to the thread). The fastest move is the move we avoid
doing, so I rather wouldn't add those parts in the first place.
However fixing the fence relation turned out to be a lot trickier, both
because of the missed data race and also rmw-sequences, essentially I
would have had to disambiguate between xfences and fences already in
this patch. So I did this minimal local fix for now and we can discuss
whether it makes sense to get rid of the '& int' once/if we have xfence etc.
than I. I am relatively only recent with even opening up the CAT code.