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 "Terminate" flag with an unknown delay?

Very important: InterlockedExchange is not a memory barrier, except on x86.

It's not a semaphore/signal, it's just a field. It will never be instantaneous since it can only have an effect once the target thread actually tries to read it. Wrapping it in a bunch of synchronisation primitives will make the whole system slower with no real benefit.

Jonas

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 guess the "Terminate" field is actually about cache coherency.

But I could not find any reliable info, if
- a memory barrier is needed for cache coherency.
- a memory barrier even affects cache coherency

I would assume that InterLocked will make sure (maybe as side effect) that there is cache coherency ?
I.e. it makes sure (on all platforms) that the particular value that it did set, will be immediately visible to all other threads (if they use interlocked.... to read it)?

At least that is what I always thought. If that is not the case, I have a lot of code to fix...
I acknowledge that
- a value set with InterlockedExchange by one thread
- may not be visible in other threads, if the access it *without* InterlockedExchange
- does not affect the visibility of any other memory between threads.

How far off am I ?

From what I found:
https://stackoverflow.com/questions/30958375/memory-barriers-force-cache-coherency

Cache should update between all cores (and cpu?), and therefore threads should have up to date values.
Well, almost.
Apparently there can be tiny bits of a lag, sometimes.

Memory barriers will (among other things) remove that lag.

Leaves the question, if it is enough if one thread issued the barrier?

I think https://www.kernel.org/doc/Documentation/memory-barriers.txt is pretty good.

Jonas

Martin Frb 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 after it gets set, so who cares if the target thread doesn't see its new value immediately?

If you do care, then you need some other way to signal the target thread to immediately drop what it's doing, but then there is no point in checking the Terminated property anymore since that signal will already have performed the same function.

Yes.

It's correct.

Jonas

The new, virtual TerminatedSet method can be used for such a signal. It's called after FTerminated was set to True an can be used for example to trigger an event the thread might be waiting on.

Regards,
Sven