On Tue, 6 Jul 2021 at 15:32, Giovanni Mascellani gmascellani@codeweavers.com wrote:
Il 05/07/21 14:28, Henri Verbeet ha scritto:
Well, yes, it doesn't. Are you saying we need those here though?
I think so.
My understanding is that we are relying on undefined behavior, and I think we shouldn't do that, because it might break randomly at some point after unrelated changes, or with a different compiler; and it could result in a kind of bug that is very painful to debug.
C before C11 doesn't specify a whole lot about concurrency, so in that sense we're already in trouble simply for using threads; the C standard isn't going to help us much here.
As I understand it, we don't need a barrier here because this is an (aligned) CPU word sized variable that's only updated with InterlockedExchange(). I.e., the combination of InterlockedExchange() for stores and volatile for loads should be sufficient for preventing torn/fused/invented loads and stores, as well as any reordering we care about. I don't particularly mind being wrong about that, but I'd need something more concrete than (essentially) "volatile is not a full memory barrier".