Ok, I got a bit further.
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.
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....
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?
Thanks again
Martin
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
