Am 22.08.2020 um 18:45 schrieb Jonas Maebe via fpc-devel:
On 22/08/2020 17:39, Martin Frb via fpc-devel wrote:
I guess the "Terminate" field is actually about cache coherency.
Yes, but as mentioned earlier it's in general completely useless to
force the overhead of cache coherency for it. By
On 22/08/2020 17:39, Martin Frb via fpc-devel wrote:
> I guess the "Terminate" field is actually about cache coherency.
Yes, but as mentioned earlier it's in general completely useless to
force the overhead of cache coherency for it. By design it's not
something that will be checked immediately
On 22/08/2020 17:39, Martin Frb via fpc-devel wrote:
> Is there some really good article (better than the wikipedia
> https://en.wikipedia.org/wiki/Memory_barrier) on
>
> - memory barrier
> vs
> - cache coherency
> vs
> interlocked
> ?
I think
On 22/08/2020 17:39, Martin Frb via fpc-devel wrote:
Is there some really good article (better than the wikipedia
https://en.wikipedia.org/wiki/Memory_barrier) on
- memory barrier
vs
- cache coherency
vs
interlocked
?
From what I found:
Is there some really good article (better than the wikipedia
https://en.wikipedia.org/wiki/Memory_barrier) on
- memory barrier
vs
- cache coherency
vs
interlocked
?
On 22/08/2020 16:57, Jonas Maebe via fpc-devel wrote:
Very important: InterlockedExchange is not a memory barrier, except on
On 22/08/2020 16:09, Martin via fpc-devel wrote:
> procedure TThread.Terminate;
> begin
> FTerminated := True;
> end;
>
> Should that not in some way deal with memory barriers? E.g.
> InterlockedExchange or similar?
Very important: InterlockedExchange is not a memory barrier, except on x86.
>
procedure TThread.Terminate;
begin
FTerminated := True;
end;
Should that not in some way deal with memory barriers? E.g.
InterlockedExchange or similar?
And the same for the "Terminated" property, should that have a getter to
do the same?
As it stands, afaik a thread could get the
