On 24/08/2020 02:11, Martin via fpc-devel wrote: > Assuming the following > (and not counting on Interlocked... doing any Barriers itself) > > Thread 1 > Foo := val; // normal assign > WriteBarrier; // make sure above write to Foo is executed, before the > next write to flag > InterLockedIncrement(Flag); // needed for the lock, if others do > write access too. > > Thread 2 > If InterLockedExchangeAdd(Flag, 0) > 0 then begin > ReadBarrier; // make sure below read is executed only after the > read of the flag > myval := Foo; > end; > > That should get the correct value of Foo. > Even if run a million times, and in all of this the read of Flag > eventually happens exactly one cpu cycle after it was set.
Yes. > Now the Examples I've seen all are showing cases where the re-orderable > assignment are in close proximity to each other. > On the other hand compiler and CPU are getting better and better. So > there is nothing that would in theory stop them to swap read/write order > over any amount of statements.... Correct. In particular on multi-socket systems, or e.g. Ryzen processors with multiple core/CPU complexes, this is quite possible. > So even if (in Thread 1) I returned from a subroutine (which could be > inlined for all I (don't) know), done some other work, and only then set > the flag. > If I want to be sure, any value that was written in the subroutine is > written before the flag gets set, then I should do a WriteBarrier? > Or is that paranoid? It's not paranoid, it is the only correct way to write the code. Jonas _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
